Simple query loop?

[DonNH]

OK, still a newbie . . . .

Need to send a query every 3 seconds to an external device (robot) using a predefined function block.

If I could set a task period for that length of time it would be easy, but that doesn't appear to be an option.

Should be a simple loop and timer combination, but I'm not quite picturing it and surprisingly haven't been able to find what I need in an internet search.

So,  asking the brain trust here.

Thanks

[pturmel]

Just a timer. No loop. (Tasks run repeatedly, giving you the option to perform loop-like behaviors without an actual loop.)

Have 3-second timer include its own output contact as NC in its enable, causing it to restart repeatedly.  Use that done bit (true one scan per 3 seconds) to fire your function block.

[DonNH]

So my quick interpretation of what you said is this, but it doesn't appear to really do anything in simulation so I'm thinking I'm still missing something.  Too tired for me to think much beyond that.

[DonNH]

Looks like maybe that does work as shown, but the output from the timer is a short pulse so in simulation it doesn't show up?

I added a 1s pulse timer to the output of the first timer, and it looks like it's now working.

Not sure if I need to leave the pulse timer in, but it shouldn't hurt.

Will try this out once I get my PLC reconnected to the network.

[DonNH]

And a couple "style" questions - probably both personal preference, but interested in people's thoughts:

1) Combine the two above rungs into one, to keep things shorter?

2) Use latching circuits to turn on the process, use the Set and Reset as shown below . . . or, since this will probably be a separate program/task . . .  turn on that task from outside?

I think I've seen an article somewhere discussing the pros and cons of using Set/Reset, but I haven't seen any discussion of where it makes sense to run/stop programs.

 

 

Edited October 12, 2023 by DonNH

[pturmel]

Your predefined function block probably has documentation that states whether you need to hold its input on until complete, or if it fires on a rising edge.  If the latter (fairly common), then you don't need to extend the single-scan pulse.

(Not being able to see single scan pulses is also common.)

[pturmel]

I avoid Set/Reset (Latch/Unlatch) coils where a simple seal-in branch meets application requirements.  Specifically to be as maintenance-friendly as possible.

There are two places I regularly use them:

• In processors where Latch/Unlatch yields a persistent state (through program mode or power cycle) and a seal-in branch does not, and the application needs that bit state to survive an interruption.  Typical in Allen-Bradley processors.
• To set bits of registers that implement a "bar graph" style sequencer, where the sequence restarts by clearing the whole register.

I avoid using stop bits or interlocks in the PLC where stop==true.  That implies that the wiring and/or remote rack communications are not fail-safe.  (Cut wire => stop.  Lost comms w/ zeroed comms buffer => stop.)

[DonNH]

There's no real documentation on these function blocks (Omron's ARCL blocks) so I'll have to figure that one out. The ones I've used don't seem to mind being held on, so I'll probably just do that.

 

[photovoltaic]

48 minutes ago, DonNH said:

There's no real documentation on these function blocks (Omron's ARCL blocks) so I'll have to figure that one out. The ones I've used don't seem to mind being held on, so I'll probably just do that.

 

In the sample program and manual for the ARCL library it appears they can and should be held on until completion is confirmed.

[Crossbow]

I have a 98 page manual on the function blocks.  The download I got had the library, sample project, manual, and starting guide.

ARCL_Comms_Lib_1.7.0_Manual.pdf

Any time they use EXECUTE as an input name, it can be pulsed.  It would be called ENABLE if it had to remain on.

[DonNH]

Are all the files you received labelled as 1.70? The ARCL files I was given in March of this year are labelled 1.4.3, and the ones on the Omron site are labelled 1.4.1. All of the input names seem to be Execute.

Maybe the newer rev has more of this figured out.

I'm finding it's semi-random on whether they need to be held on -- I have several WaitMsg blocks, which seemed to be fine just being pulsed - I use a large value for the timeout if needed.
Then I made changes elsewhere in the program, and one of the WaitMsg blocks stopped functioning - didn't appear to be starting or finishing. I put a 5 second pulse before, which didn't help, then changed that to 60s and it works (time from triggering the block until the message (arrival at a position) is issued is about 35s if there's no delay along the way.

I also have a number of GotoGoal blocks - most seem to work fine, but a couple will start the robot towards the goal but not finish the block when they arrive - will mess with these next.

So, I guess I need to go back and latch all of these function blocks.

 

[BE]

On 12/10/2023 at 10:41 PM, DonNH said:

And a couple "style" questions - probably both personal preference, but interested in people's thoughts:

Kinda off topic, but you can call the 'done' contact "puls1.Q" and it will do the same job as the "done" bit. This is something I find useful, particularly when you are using a timer's output to reset itself, and especially when you are playing around with testing ideas and concepts, as it eliminates another bool variable from your code.

There is nothing wrong with having the extra bool, its just personal preference at the end of the day. And sometimes having that extra bool does make things a bit easier to read later on 

[Crossbow]

Keep in mind that puls1 is a local variable, and cannot be displayed on an HMI.  That is why you typically attach a global variable to the output.  Instance names for function blocks cannot be global variables in Sysmac, not sure why...

[DonNH]

Crossbow - did you see my question regarding the ARCL file versions?  I'm wondering if I should be asking my Omron contacts for updated files.

I already have a bunch of unanswered questions pending with them - might add to the pile.

[Crossbow]

On 10/25/2023 at 2:37 PM, DonNH said:

Crossbow - did you see my question regarding the ARCL file versions?  I'm wondering if I should be asking my Omron contacts for updated files.

I already have a bunch of unanswered questions pending with them - might add to the pile.

The ZIP I have says 1.70.  So there may be a newer version than is posted on their website.  Wouldn't be the first time.

[photovoltaic]

12 minutes ago, Crossbow said:

The ZIP I have says 1.70.  So there may be a newer version than is posted on their website.  Wouldn't be the first time.

1.70 is the latest. Previous versions were 1.60 then 1.43

[DonNH]

I'll have to see if I can get the updated version from my Omron contacts, hopefully with some description of what the changes are.

I have that question within a few other questions that I'm waiting to get responses on.

Omron is being very sluggish with responses - either directly from the applications engineers I have contact with or through their support portal.

[DonNH]

On 10/27/2023 at 0:49 PM, photovoltaic said:

1.70 is the latest. Previous versions were 1.60 then 1.43

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?