Hi there! Anybody can help me?
I am using a VC model that receives signals from PLC. When I run the code line by line, it works fine. But when i run code, the model don´t drop the piece. I arrived in a dead end and I don´t know how to get out.
Handling v2.vcmx (1.2 MB)
triggerCondition(lambda:kiwi) is trigged by VC’s part.
After part arrives in VC, you need to wait signal from PLC, VC and PLC need time to communicate.
You cannot check PLC signal status immediately.
Sample code can be found in Help → Python API, search vcScript.
Use condition or triggerCondition to wait signal from PLC.
Hello! Thanks for the help.
My triggerCondition(lambda:kiwi) is trigged by VC´s part and PLC signals, because “kiwi” is a global variable appended in def OnSignal():
Maybe I don´t understand what did you say.
Whoa! I understood what did you say, but not believed that was just it to do… I inserted a delay in the line before the triggerCondition and… BAM! Everything work fine.
Thanks a lot @chungmin !!
Note that using the Python API delay function is not really a reliable way to allow for communication time.
This is because it makes a delay in simulation time, which may not follow the real time (wall clock time) that the Connectivity feature and PLCs operate in.
Even if you run the simulation at 1x speed in “real time” mode, any sudden delay such as UI lag when selecting a component or switching a tab will cause the simulation time to momentarily lag behind the real time and then do a “sprint” to quickly catch up. So if you get 1 second real time pause due to some long event, the simulation time may advance 1 second in e.g. 10 milliseconds of real time. This will obviously cause your delay() to not work as a way to wait for communication to happen.
The reliable way to do such communication is to always have some kind of acknowledge-reply for each control signal which you wait for or maybe just a general “heartbeat” counter. Another less reliable but better than simulation-time delay is to make a real-time delay using the Python time module. Running your simulation in fixed step mode will also avoid the sprinting behavior, but then you don’t have precise control over the overall speed of simulation time in relation to real time.
Thanks for your considerations @TSy ! Can you tell me how I can make this general “heartbeat” counter in VC? Or you can point direction?
To ensure that a communication cycle VC → PLC → VC has happened, you could create a counter that is incremented on VC side and then you receive an “echo” or “acknowledge” from the PLC.
So basically create 2 integer signals or properties in VC, one output (VC → PLC) and one input. Then write a script that listens for the input signal value change and when the value equals the output it adds 1 to the output signal’s value.
Then connect the input and output to an integer variable on the PLC using the Connectivity feature.
You may need to have the script set the output to 1 in OnStart, but after that you should get the input and output signal values incrementing as quickly as the PLC communication allows.
Using such counter to wait for communication in logic I have not actually tried, but I don’t see why it wouldn’t work either.
To use this as a mechanism to wait for PLC communication in your scripts, you could just read the current value of the intput signal (PLC → VC) and then use triggerCondition to wait for the signal to reach that value + 2. Waiting for value + 1 might not be reliable if there are some queued events still to be processed. Alternatively you could wait for the current value of the output + 1 to appear in the input instead.
You could have multiple of these input signals from same counter. Just either connect the signals on the simulation side, or pair the signals to the same PLC variable in Connectivity. If you go with the second option, have the variable pairs in the same variable group so they stay in sync.
I guess it would be feasible to create a helper component for this using action containers or something. The problem is that each script that requires such logic will have to wait for different value of the counter so it can’t be simplified to a Boolean signal.
