Is it possible to assign a true value to 2 digital output at the same time by using SET command...

Not that I am aware of, I tried playing around a bit with the formula field in the set dialog and it didn't do anything.  You could use a single line script code like this:



Or if you really wanted to cheat you could write your own custom script that you could do anything with such as this script which allows you to specify a range of outputs to turn on all at once...notice it turns all outputs off first and then turns on the selected outputs



Here is the code that I wrote on the robot....



So the first time I will turn on outputs 0 and 1, the next time it will turn on outputs 3 through 6 , then 0 through 2,  and finally 1 through 5.  Remember outputs and inputs are numbered 0-7, not 1-8.

The wait commands are just so that we can what the program is doing

Here is what it looks like on the IO tab when the program runs.




Hope that this answers your question but also gives you some insight into how the robot can be customized to do about anything you can imagine program wise

Thanks for your answer Matthew. I'm still wondering, is it the "sync()" function you use at the end of your program that ensures synchronicity between the activation of the outputs? Documentation isn't really clear about it: "Uses up the remaining ”physical” time a thread has in the current frame."

Although it might just be a refresh time issue, we can even notice delays between outputs activation in the video you provided.

Do you have an idea of the maximum possible delay between the activation of two outputs using this workaround and do you think it would be the same with non-physical IOs like Networked EthernetIP variables for instance?

Thanks for your help!

So here is where it can get a little confusing....so the robot is operating at 125 Hz or every 8 milliseconds (ms).  Which means every 8 ms the controller is sending a command to the robot, when it is moving you are actually seeing thousands of points stitched together in 8 ms time slices, this is the physical time of the robot. When you are sending commands like this program does those can be processed in less than 8 ms so there is a chunk of time where nothing is happening and the robot is looking for that time to be consumed, hence the sync() command.  So in this instance lets say that turning on an output only takes 1 ms to execute the command, when I am turning on 4 outputs I would only be taking up half of the time of that physical slice of robot operating time, so I need to get my operation back in sync with the robot, so I use sync().  The other option is to use a wait command (if you are using URScript it is the sleep command) and give it at least 8 ms to wait.  The difference is this will always wait 8 ms, so in that scenario above the fastest my script could run would be every 12 ms, not 8 ms.  Once you can get your head around that issue everything else becomes easier.

The reason that you see a delay in the video probably has more to do with the simulator than the timing between events occurring.  The actual outputs on the robot are pretty darn fast, we actually had to put delays between the outputs turning on when dealing with safety systems so that the safety system could see the small lag, less than 100 milliseconds, and not think that someone had wired the two palm buttons together.  I feel like I have seen somewhere the actual specs for turn on and off time but I can't seem to find it quickly.

I know when we fire two outputs at the same time you can't see it happening with the naked eye, however scientific that is.

As far as EthernetIP or ModBus they are going to be slower, we have had issues in the past with modbus inputs on a punch press where we could not reliably see the input signal on the robot because it was happening too fast for the modbus communications to get it to us, we wired it directly to the robot and have since made over 500,000 parts without ever missing an event.

Thanks Matthew for the clarification!

Thanks Matthew for you answer, I will try that later...

Bye