PLC IDE Ladder Exection

[kienzguy]

This might be more of a firmware question on how Ladder Executes, but something doesn't seem quite right based on what I'm testing.

I made a quick demo to show some students how to do basic sequences, and the OTEs (output coil energize) are not working as I expected. I'm not sure if it's a result of how the live debugging works or if the PLC evaluates ladder in a way that doesn't make sense. The issue I have is that the rung in condition can be false, but the OTE is still active. I don't have duplicate destructives (I know better than that) so I don't see why the output is still on when the rung in condition is true. If this is how this is supposed to work, then I would request that it can be fixed since that is not how ladder should execute based on every other PLC I've used.

[apf1979]

@kienzguy

so I don't see why the output is still on when the rung in condition is true.

rung condition false?

I haven't had a chance to use the Arduino PLC IDE yet but a few things I've seen in other software. Is there a run/program/test mode and the mode you have it in is preventing memory updates? Is that routine active? Is the bit part of an integer value and you're writing the decimal value separately? Does the input condition flicker or change state rapidly? Sometimes you get an effect where buffering, debouncing, etc., can make odd things render.

[kienzguy]

The rung in condition in ladder refers to the logical statements to the left of the outputs. So in my screenshot, I have underlined the rung in conditions that are needed to be satisfied before the outputs will be turned on. In this case, dummyBOOL[1] is off, and stepSeq is not equal to 20, so these conditions aren't true, which should result in the redLight and sysLEDOutputs[1] variables to be off. Ladder executes left to right, top to bottom. The output relay is physically on which matches what the online debugger shows. But it really should not be on based on how this should be scanning.

Edit: just read your reply closer. Yes, when the rung in condition is false. Sorry for overexplaining something you already understood.

[apf1979]

@kienzguy

The output relay is physically on which matches what the online debugger shows. But it really should not be on based on how this should be scanning.

Are redlight and sysLEDoutputs[1] both on? The [1] designation tells me it's part of an array or a binary bit that's part of a word and so something else could be writing to it.

[kienzguy]

Yes, both sysLEDOutputs[1] and redLight are on (and highlighted in blue in debugger mode) and should not be on since dummyBOOL[1] is off and stepSeq is not equal to 10. Nothing else is being written to those variables (I doublechecked this) as I know duplicate destructives can cause weird behavior. This is why I think something might be incorrect in how the PLC evaluates ladder logic.

[apf1979]

Are you willing to share your project? I've downloaded the software, but haven't used it yet. I can't think of anything else from what you've posted though?????

[kienzguy]

updatedCOMPort.zip (6.4 MB)
Here is the project. It seems to me like it doesn't execute as I'd expect. If I have to truly buffer IO like old school PLCs, then I guess I'll have to do that. I'll try it but this would be a bit of a pain and an extra layer to add to this simple program I've created.

[PMarquinez]

Hello @kienzguy

I'm not replicating it properly, your case is not happening to me.

I've tried to change the state of cmdStart to TRUE, and it auto-sets to False.

I'm not that familiar with LD programming, could you try to simplify your program a bit, to focus on the issue?

Also, I suggest using the Watch window tool.

Please check that you have the latest PLC IDE Version and the PLC IDE Tools

Software

If the latest version still happening, please record a video following this:

1. Disconnect the Opta
2. Restart the PLC IDE
3. Start recording your screen
4. Download the runtime to the Opta from Resources > Opta > Download
5. Connect to the Opta
6. Upload the program
7. Add the variables on the Watch window, to double-check
8. Enable debug
9. Show the issue

Best regards, Pablo.

[kienzguy]

The maximum upload file size is 8 MB it says. I've recorded a screen capture of the steps you described but it's 256 MB, so I'm unable to share it. I've included an image instead. Ladder executes like a physical electrical circuit (normally open and normally closed contacts and output coils). I appreciate the help Pablo, but if I have to explain how ladder logic, then I'd request someone from Arduino who does understand it to look at this as well. How ladder should work is that if a normally open contact is closed (variable is equal to 1), then the output coil should be on ONLY when that condition is true. The exception to that is when using a set/reset (aka a latch/unlatch). In the case I'm showing, the redLight variable is an output coil and the condition dummyBOOL[1] is a normally open contact that is open (variable is equal to 0). In that state, redLight should be off. Important note that is definitely different than someone testing my code is that greenLight and redLight are alias variables to relay outputs 0 and 1 on the device. That shouldn't make a difference, but just a note.

[PMarquinez]

Hello @kienzguy I'm familiar with LD, but I've tried to replicate and I did not share your issue.

What I was asking was for some kind of timestamps and the variables, so I can check that I'm not wrong. Cause what I see is basically a "ladder" of blinks for the dummyBool array.

I will try to tweak the program a bit, to see if there is something wrong going with the TONs

My issue was that i was getting stuck the dummyBool[0] to true, anything else

[kienzguy]

@PMarquinez

I'm not that familiar with LD programming, could you try to simplify your program a bit, to focus on the issue?

Maybe I misunderstood this statement. I read that meaning you aren't as comfortable with ladder logic.

[kienzguy]

So if you aren't able to recreate it, do I need to do something else?

Yes, basically the program is meant to sequence through outputs (I have two physical outputs and 4 logical outputs, but was originally using the built in status LEDs). The only reason I have that dummyBool array is because this ladder editor does not allow starting a rung without a discrete contact. This is something I asked about in a separate forum because this is an archaic limitation that is not present in modern PLCs.

yes, I could see the TONs having an issue, but if the OTEs are on when the rung-in condition is false, then there has to be something wrong with how the PLC is evaluating that rung. Not sure if I am making sense and I do appreciate the support.

[PMarquinez]

The issue right now is on the IO Mappings

The TONs are ok, check the following video

I've moved the task onto fast, and change the timing to 1000ms so its clear each cycle.

PLC IDE LD program issue, forum post

If you change yout stopPB and use a local variable, it will work as expected.

[kienzguy]

I have moved the routine into the fast task (10 ms). You mention changing the timing to 1000ms. Do you mean changing the task period to 1000 ms? Because that is not considered a fast task in the industry. That's slow enough for slow dynamical processes, but not something like this. I think you mean changing the TON presets to 1000 ms. I'm not following why I should change the stop pb to be a local variable. That defeats the purpose of what I'm trying to do as I am using a physical button. From your video it looks like you are simply removing the stop which again defeats what I'm trying to do functionally with that button.

I see what you are showing is that the dummyBool array bits are going off and on correctly, which mine already do. The issue is that my physical outputs (sysLEDOutputs[x]) are not turning off when the rung in condition is true. Reference the previous image I have shared. What I am showing here is completely wrong. If dummyBOOL[1] is off, then right off the bat, sysLEDOutputs[1] and redLight should be off. On top of that the EQ instruction should also not evaluate as true since stepSeq is 0 which is not equal to 20.

[kienzguy]

I think it might help for me to add a functional description of what I'm trying to accomplish:

Here is a functional specification of what I'm trying to do. Basically I want to hit the start button, the lights sequence through every half of a second and continue to do so until I hit the stop button. I have done this on other PLCs and have zero issue with it.

Digital Inputs:
startPB (wired normally open to input 0)

stopPB (wired normally closed to input 1)

Digital Outputs:

greenLight (output 0)

redLight (output 1)

Sequence (started when startPB is on, can be interrupted when stop PB is pressed):

Step 0:

IF startPB or sysButtonInputs[0] (button on device) sees positive edge transition or dummy BOOL[4] is on and stopPB isn't pressed (end of sequence so it loops continuously until stopped THEN
Move 10 into stepSeq, Set DummyBOOL[0] and reset the rest of the DummyBOOL array bits

Step 10:

IF stepSeq is equal to 10 THEN
sysLEDOutputs[0] is on (only when stepseq is equal to 10) (note that sysLEDOutputs[0] is mapped to greenLight in the IO mapping routine)
500 ms timer when sysLEDOutputs[0] is on, Move 20 into stepSeq and set dummyBOOL[1]

Step 20:

IF stepSeq is equal to 20 THEN
sysLEDOutputs[1] and redLight are on (only when stepseq is equal to 20)

500 ms timer when sysLEDOutputs[1] is on, Move 30 into stepSeq and set dummyBOOL[2] and reset dummyBOOL[1]

Step 30:

IF stepSeq is equal to 30 THEN
sysLEDOutputs[2] is on (only when stepseq is equal to 30)

500 ms timer when sysLEDOutputs[2] is on, Move 40 into stepSeq and set dummyBOOL[3] and reset dummyBOOL[2]

Step 40:

IF stepSeq is equal to 40 THEN
sysLEDOutputs[3] and redLight are on (only when stepseq is equal to 40)

500 ms timer when sysLEDOutputs[3] is on, Move 0 into stepSeq and set dummyBOOL[4] and reset dummyBOOL[0] reset dummyBOOL[3] and reset cmdStop

[Gav1n]

@kienzguy did you ever figure this out? I am experiencing similar issues with PLC IDE executing ladder logic that other softwares would execute fine.

[drumcrazd]

I found I am also having the exact same issue, its like the EQ block is still passing the signal through the program even when it's false. has anyone found a fix for this?

[kienzguy]

I have not seen a fix for this. It has been a while though so I wonder if there is a newer firmware that addressed this issue.

[kienzguy]

Sadly I have not seen a fix for this. Hopefully a firmware update would address it? I haven’t looked into it recently but it seems I’m not the only one experiencing the issue.

[drumcrazd]

I did find a work around by replacing the EQ blocks with bits and controlling them with another ST program but it's so strange that the EQ block just passes the signal through. I only ended up seeing "True" over the output of the block when the timer finished, turning the output on and technically making the end of the rung "True"