Hello all,
I’ve been facing a problem with multiple layouts so far,
Unfortunately, I won’t be able to share my layout for confidentiality reasons.
The problem that I had ,
a machine cell sends signal to loading robot, waiting for a signal back from loading robot , but the loading robot is busy with a task.
10-15 sec passes from when the signal was sent. When the loading robot finishes its previous task, it no longer listens to that signal, and the machine cell remains waiting for a signal back.
Even though the signal is green/true.
It’s the same issue mentioned in this topic
How can I tell the robot to “keep listening”?
OR
How can I increase the time in which the robot “keeps listening”?
What’s the default time given from when a signal is sent, and a signal is expected to be listened to? is it 5sec? 10 sec?
ummm, it sounds like this problem is a WaitTrigger problem, I envision your operation to be something like, your mechanism runs to a certain process sends a validation signal to a running robot and waits for him to range to confirm the signal, but in your robot program, you also write a wait signal program, but in the program, you confirm the WaitTrigger function. This function is used to wait for a new signal to be triggered, but in fact, the rising edge of your validation signal was triggered a long time ago, and even though your validation signal is still True, it won’t trigger the code to continue running.
If most of your problems are caused by the above, then I would recommend turning off the WaitTrigger feature, but if you don’t want to turn it off, you may need to use other ways to do the verification/validation, for example, if you have a mechanism that also sends signals to the robot through the program panel, you can try the Synchronization feature in the Program Panel, which allows for more real-time signal monitoring, or you can use the Synchronization feature in the Program Panel to monitor the signal. You can try the Sync function in the program panel for more real-time signal monitoring, or you can use while in the robot program to listen in real-time.
In general, from what you’re saying, I think you’re listening to the rising edge of the signal and that’s what’s causing your program to fail.
Hey @BAD ,
Your description is correct.
I need the WaitTrigger function, so I have to keep it active.
“I think you’re listening to the rising edge of the signal and that’s what’s causing your program to fail”
That’s correct. Even though the signal appears green/true, the robot missed listening to it.
I am looking for a solution within the “Process” tab. Is there a software default settings in which I can manipulate/alter to force the robot to keep listening beyond the rising edge of a signal?
I think you misunderstand how the robot programs work. Each program only executes a single statement at a time and thus when the WaitSignal statement is not currently active in the program it does nothing.
The signals are just a value (Boolean, Integer etc.) and a mechanism to get a callback when that value is assigned (value doesn’t necessarily need to change). The WaitSignal statement checks that value and optionally waits for a callback (WaitTrigger), but it only starts listening when the statement starts executing, and then stops listening when the statement is done.
If you need to communicate asynchronously between your robot programs, you need to implement your own signaling system using e.g. component properties and some form of “acknowledge handshake”. The robot programs are quite limited compared to PM processes on using signals and properties.
Okay, glad we have a general idea of the source of the problem so far.
I don’t know what signal you’re waiting for, or whether that signal will trigger multiple times in a given situation, but as I said in the content of my previous reply, if waiting for a new rising edge of the signal is necessary, then my suggestion would be to replace what you’re doing. I’m not sure what you’re currently doing, I can only tell you what’s available in VC to solve the problem (which gets complicated if your final target involves OLP). In the program module, there is a feature called Synchronize, which is a more real-time way of listening, and it comes in handy when both of your components are programmed with the program module, it’s used to wait to see if the specified component has sent the specified validation message using Synchronize, and it will always wait for the validation message to appear, whether it’s already appeared or in the future.
Also, as TSy said, robot programs are very limited in their use of signals and attributes, so you’ll have to build your own interactions, such as through Synchronize or python scripts. As for your comment that you’re looking for ways to do this in the process module, the fact is that the waitsignal in the process module is essentially the same as in the bot program.
Thank you @BAD@TSy for your explanation.
I realized that I had a poor understanding of how the signal, and statement execution works in VC.
I’ll look into another solution to make it work.
