a one shot energizing an OTE

[zachary.wilson]

Howdy Everyone,
So I have been retrofitting a cell to run different fixtures and updating it with new drives and a few other things. It runs Studio Designer. It is actually to take a couple of the removeable fixtures from one cell so we don't have to change them over. Some of the logic I just copied over and wasnt too worried about. But then when it went to run it didn't work. After digging for a while I found I wasn't getting OTL energized to finish out the cycle, I followed the bit that makes the line tru back to other routines, where I found an OTE getting turned on by one bit with a ONS after it. I tried a couple different ways to make sure it was happy, before I ultimately got rid of the ONS and put a timer and a TT bit that ran for 2 seconds. I would normally assume it was because it didn't have enough time to register in a completely different program. But the weird thing is, the routine with the ONS in it, was a copy from another PLC, that runs fine.
Does anyone have any idea other than i am just missing it because of scan times?
I always assumed an ONS stayed on for 1 scan of the entire program, is it just for that routine, and it just happens to work in the other program? thank you. I attached the two rungs of logic, they are in different containers. it was identical between the two machines, but only worked on one of them.

 

[TheWaterboy]

I'm not going to be the one to open a docx file attachment to see the example, (use JPG or at least PDF) but in A/B an ONS only sets for the one scan where the input is set, and then as long as the input doesn't change neither will the output.

 

[bernie_carlton]

Assuming the OTE is used within one scan it should work. The OTE is used to set a latch OTL. Temporarily place a counter in parallel with the OTE and one in parallel with the OTL. See if each increments.

 

[drbitboy]

Is the I/o scan synchronous with the program scan in the PLC where the old code woworks?

Because that may not be the case in the PLC programmed by Studio Designer.

 

[zachary.wilson]

Howdy Everyone,
I didn't even think about it being a word document, I reattached it as a word document. I have added test bits/counters at the initial line where the bit is turned on, they work there but not at the xic line where it latches another bit.

 

[kekrahulik]

1. You say you added a counter at the initial line - did you add one at the OTL line too?
2. Anytime a latch "isn't working", look to see what the unlatch is doing (adding the counter after the latch would make that question irrelevant).
3. You say these are in different programs. Are they in different tasks? If the OTE is in a timed task running every 10msec and the OTL is in a task running every 30msec, the OTL may never/rarely see the OTE fire.
4. I assume the second program is actually running? (being called by a JSR)

 

[Aardwizz]

You refer to the coil and contact being in two different programs.
Are those programs in two different Tasks as well?
If so, what are the scan rates of the tasks (assuming periodic)? How about the priority, if they are the same.

If run into this problem often, where a one-shot bit (however it's fired) is not On long enough for one task to see it from another.

I've even had one program that had a one-shot bit in a Continuous task that successfully fired a bit in a periodic (PID) task in an L70 processor, because the scan time of the Continuous task was significantly longer than the PID one. But when I switched to an L80, the scan time of the Continuous dropped by 90%, and now the periodic task only executed once every three scans of the Continuous task.

It's things like this that make me not a fan of Rockwell's "standard" of using Periodic tasks for everything.

Sure, I've seen issues in really massive programs with tons of distribution and communication where slowing down the execution of non-essential tasks is important. And yes, things like PIDs and Totalizers need to have a solid metronome update frequency.

But that's you don't bog down the system with high-priority periodic task: just have them when you need them. We used to make due with just a single STI routine, and these new processors are rockets compared to those PLC-5s and SLCs.

 

[drbitboy]

So the question is this:

Will the routine that contains the lower logic (BST XIC .Teach_PB NXB XIC .Teach_Activate BND OTL .Teach_Active) always be evaluated between two successive* evaluations of the upper logic (XIC .Teach_In_Progress ONS ... OTE .Teach_Activate)?
​

Because if the upper logic's ONS sees a rising edge on one evaluation, but that same upper logic is then evaluated a second time before the lower logic is evaluated, then the lower logic will miss the event when the oneshot has a value of 1.

For example, if both of those rungs' routines are called unconditionally as part of the continuous task, then it does not matter in which order they are called; the OTL logic could be triggered EITHER on the same scan cycle and after the ONS logic is evaluated and fires, OR on the next scan cycle and before the ONS logic is evaluated and clears.

In other words, the more pedantic version of what others have been saying is that the OTE-written bit (.Teach_Activate) does do not only maintain its value of 1 until the end of the scan cycle when it is set by the oneshot, it also maintains its value beyond that until the next time that same oneshot logic is evaluated**, whether that next evaluation is 1 millisecond later during the next continuous scan cycle or two days later.

* presumably on two different scan cycles, but not necessarily: perhaps one or both of these are timed-interrupt routines.

** assuming the OTE after the ONS is the only place where the oneshot result (.Teach_Activate) is written.

Perhaps a more reliable way to do this would be to change the upper XIC=>ONS=>[OTE .Teach_Activate] logic sequence to be XIC=>ONS=>[OTL .Teach_Activate], and then add an [OTU .Teach_activate] instruction to the lower logic. That would deterministically pass any (or multiple) the rising edges of .Teach_In_Progress to .Teach_Active.

 

[drbitboy]

Perhaps a more reliable way to do this would be to change the upper XIC=>ONS=>[OTE .Teach_Activate] logic sequence to be XIC=>ONS=>[OTL .Teach_Activate], and then add an [OTU .Teach_activate] instruction to the lower logic. That would deterministically pass any (or multiple) the rising edges of .Teach_In_Progress to .Teach_Active.

I.e. like this:

​

 

[zachary.wilson]

Thank you everyone for the replies,
Drbitboy, i ended up doing pretty much what you showed in some of the spots, others i added a 2 second timer and just had an xic that was for the TT. Real question i had was why it worked in the other program and not mine, but i'll look into the scan times. I know it isn't a problem with the plc itself, as i ended having to upgrade mine from a L30er with 1mb of memory to a L36erms with 3mb, (just what we had available, didn't need the safety side of it, and the original cell I am copying has a L33er in it with 2mb of memory.

 

[Aardwizz]

I.e. like this:

View attachment 67110​

For a one-off solution, passing a 1 with a set / reset pair is the correct solution.

I've had applications where the operator wanted a "Put everything in Auto Mode" button.

Being a button, it needs to be effectively a one-shot: set by the HMI, reset by the PLC when acted upon.

But the devices live in various Tasks, Programs and Routines, so a single PROG_ALL bit couldn't be reset individually, because other objects needed to see that '1'.

It was too much of a PITA (and prone to error, and not future-proof) to code each Auto mode change request individually; much easier to add an Input to the AOI to tie to PROG_ALL.

So sometimes keeping a bit high for a TON.TT is sadly the best solution.

Depending on one's definition of "best", as always.

 

[drbitboy]

Real question i had was why it worked in the other program and not mine, but i'll look into the scan times.

PLC programming is primarily about time, so understanding when something happens is more important than understaning what happens.

Along those lines, note that, in Logix PLCs, the I/O scan cycle is asynchronous with the program scan cycle. I.e. the value of an individual input can change between the beginning and the end of a scan cycle, which can mess with logic that does not account for such behavior.

 

[drbitboy]

So sometimes keeping a bit high for a TON.TT is sadly the best solution.

Depending on one's definition of "best", as always.

That's a really good point.

Usually when I add a timer or a delay to code to make something work, it is only temporary i.e. for debugging to find out what the real problem is. But yes, that "sadly" does sometimes take up permanent residence.

 

[PLCDontUQuitOnMe]

This looks like a Centreline Flexfast cell? We have quite a few here so I recognize the code

 

[MikeyN]

This looks like a Centreline Flexfast cell? We have quite a few here so I recognize the code

I was going to say this exact thing!

My program is identical to what you have posted, so I have to assume that the rest of the program is pretty similar. It is worth noting that both of those chunks you posted are between MCRs. The first one controlled by Stn1.Poka_Yoke.Mode (Rung 10 of A060_Poka_Yoke) and the second one controlled by Stn1.Config.GunA.VeriFast_Upper_Installed (Rung 1 of C010_VeriFast_Upper). Check to make sure that both of these are enabled.

It has been a while since we have had one here in our plant that we actively switched fixtures on, but if memory serves, they each had jumpers in the Harting plugs to identify which fixture was installed. Make sure you haven't forgotten that either.