DonNH

This uses a pulse timer to hold on the TON timer until it triggers after 12 hours:  

Thanks. I'll play with that.   I also just found some of the Omron webinars on Youtube that I hadn't come across before, one of which covers networking, so I'll be reviewing that -  https://www.youtube.com/watch?v=YncUUghOeU4

So I have (1) NX102 and (2) NX1P2's on conveyor units which support an Omron AMR.  Communications between the PLCs and the robot are handled using Omron's standard ARCL function blocks. I'd like to have some communication between the PLCs - mostly checking sensors & status variables, possibly triggering minor actions. Poking around the manuals and some of the Youtube videos for communications, but looks like there's lots of options, and am looking for a simple way to pass basic info between the PLC's, all of which are on the same VLAN on our network (all have IP addresses of 172.16.209.xxx). Any suggestions on where to start?  

So I obviously got hung up on the fact that there is a FOR loop within Sysmac, and didn't realize its limitations. After pondering on the comments here, it finally clicked that I should be able to create a fairly simple While loop. I think this should work:  (Conceptual ladder program, using a TP as a stand-in for the ARCL Goto function block, and taking some liberties with data types in order to keep it visually clean).       I still need to figure out why the Status variable isn't kicking back correctly, as noted in my last post - maybe this structure will work correctly for some reason.          

So I added ladder logic to the existing program which checks the status once, and if it's not correct, tries again before stopping. However, it's now giving me a weird problem: The Status variable of the function block typically returns as "Command Sent" when first triggered, very quickly changing to "Going to Goal", once the  robot responds that it has received the command. However, once I added the code to act upon that info, it stays on "Command Sent" indefinitely.  I can't see anything I've done to change the way it is called - will look harder. When I reload the original program, I'm back to normal. Looks like a variation on the Heisenberg Principal - you can observe the status or act on it, but not both.

  Ok, but I have no idea what that would look like.

In ST, I think this is what it would basically look like. The ARCLGotoXXX would be the function block I'm currently using, in the correct ST syntax. Ladder syntax shown here. TP_3 line is just a 1 second wait before verifying command receipt. IF function checks to see if the function block's Status variable is showing 'Going to Goal'.  If not, then there was a communication loss at that moment, so we'll count the failure then loop back & try reissuing the command, in this case up to 5 times total.

So I guess maybe I'm looking at this wrong - will a For , Next   ladder loop always happen within a single scan cycle? I actually want to wait about a second after the function block is issued, then check its Status variable and act accordingly. I just want the check and command reissue to happen within a loop rather than duplicating the code multiple times. Is there a different looping structure to use within ladder?  

Seems like that severely limits the usefulness of the function. I want to use it to check to see if an ARCL function block actually succeeded (I'm getting occasional short network drops), and reissue the command if necessary.. I believe these function blocks can also be called through ST, but the documentation doesn't show the syntax. I've worked out the ladder code to run through a couple passes just by repeating the command, but that would get pretty clunky if I want it to try several times.

Again, I'm missing something basic here . . . . So the Sysmac reference materials I've looked at give some details about the FOR function block, but I haven't seen anything telling me how I would actually call it up. The FOR and NEXT functions have to be attached to the left side of the ladder, so I can't insert an input to initiate the loop.  Can anyone give me the basics of how I would place a loop like this in a ladder program, or direct me to more info? As is, it will run as soon as the PLC (or Simulation) is fired up.      

Anyone successfully used ChatGPT to write ladder code? I've tried a few times with zero success. At least part of the problem is just trying to interpret the "ladder" that it creates using a very limited set of ASCII characters.   For example, I asked this question:       Can you generate ladder logic to try to correct an error condition: 1) Error condition 'error 1' occurs 2) system runs subroutine 'sub1' 3) check is made to see if error condition is still present 4) If error condition is still present, system outputs 'Stop' 5) if error condition is cleared, system outputs 'cleared'   and got this result:   +-----------------+ | Start           | |                 | |  +---[ Error 1 ]---+ |  |              | |  |              V |  |         +--------------+ |  +------[ Run Sub1 ]-----+ |            |            | |            V            | |  +----[ Check Error 1 ]---+ |  |            |            | |  |            V            | |  |    +-----[ Output Stop ]---+ |  |    |       |            | |  |    |       V            | |  |    +---[ Error Cleared ]--+ |  |            | |  +------------+ | |  +---[ Output Cleared ]--+ |  |                       | |  V                       | +-------------------------+   with this explanation:   Explanation: The ladder logic starts with the "Start" condition. If "Error 1" occurs, the system runs the subroutine "Run Sub1." After the subroutine, it checks if "Error 1" is still present. If "Error 1" is still present, it outputs "Stop." If "Error 1" is cleared, it outputs "Cleared." The ladder logic then loops back to the "Start" condition.    

The _CurrentTime function looks very useful. Tried creating and using the RangeChk function - didn't seem to do anything on first try - guess I need to read up on the process of creating and using functions.

I picked the 4 second cycle and 20 second window mostly to be able to watch the values and see what's happening when I'm in simulation - actually used a much longer window. If I remove the first  rung I can actually fit the entire process into a single rung. Not sure whether there are any downsides to checking every cycle - any appreciable effect on bandwidth? Currently have a 2ms primary task and 10ms secondary, neither of which is tight for headroom.  Guess if it were an issue I could put it in its own task with a longer cycle time. Still trying to figure out where it makes sense to have separate tasks/cycle times. Just fired up the simulator and, as you noted, the times are currently the same.

I want to start an action (send a mobile robot to its charger base) at 9pm each evening. This logic works in simulation, but for some reason seems a bit awkward to me. I assume this is a fairly common thing to do, so is there a better way? Basically I check the time every 4s, convert to seconds so I can check to see if it's between 9:00 and 9:00:20 (should probably cut down the interval and time gap). Any thoughts? Also - any idea why the Simulator doesn't pull the correct clock time from my PC?  Earlier today it was about 15 minutes behind actual - just ran this again and it was about 5 minutes behind.  

I'm struggling with some of the ARCL function blocks - I had a program where all the ones I was using seemed to work correctly, once I figured out when I needed to keep the input on - I was using the Connect, WaitMsg, Goto, & ExecuteMacro function blocks. I've rewritten that program (using the new 1.70 library), but now the WaitMsg block and the QDropoff block that I added don't do anything when triggered - nothing on any of the outputs. I've reviewed my input & output variables for data mismatches, etc. but haven't seen anything which appears to be amiss. Any thoughts on what would keep these blocks from functioning?