One solution to this problem could be to use the before start method. Have a check in before start that ensures that variable is initialized to the value it's suppose to initialize too in init_variables. Usually I stick to initializing my variables in before start anyways but that's more of a preference for me.
Hi, Robotiq is now into packaging, palletizing and sanding applications. Learn more about our new Vacuum Grippers and the Robotiq Sanding Kit. 1-888-ROBOTIQ #275 (762-6847) Follow us on
You said: "... literally hit the limit number or register/Digital IO that we can add in the installation. "
-Have you thought about using: "Installation Variable" ?
Those variables are set in the installation tab, under General/Variable .
As you can set the variable value into the installation tab, they would never be flagged as "Variable_X is not initialized to a value" .
As your variable seems more permanent, this would be a good way to get around the problem.
The wait seems to be a good idea. Delaying the start of the threads shall let time for the program to initialize the variable. Using the wait in the "before start" section as suggested by Roman9 might work well if threads start is in the main or after the wait.
Usually, sockets run faster than programs. I have seen in my past life challenges with robot reading in advance coming up commands or double starting. Never on UR but as you have a racing condition at the start of your program, it might be good to keep it in mind.
Hope this helps you "Re-Start Your Production Faster" .
Regards,
David Gouffé
Integration Coach
Coach en intégration
1-418-380-2788 #275 (Outside US and Canada)
1-418-655-9221 (Cell)
Hello Pros,
I have a bit of a come and go problem with 2 CB3 UR5 that work together. My program has a ''Init Variables'' section and the variables are all initialized in it. Usually it all runs well, but sometimes I get a error message saying : ''Variable_X is not initialized to a value'. We have seen this a few times, but it has never stopped the program from starting after a couple of tries and it would usually not come back after a reboot. But on this instance, it won't work at all, we have to reload the program, remove and add again the init or reboot the robot to be able to start the program and it can come back the next day.
At first the variables in threads caused the problem, so we moved the ''wait'' in the threads to put it at the beginning of the thread instead of at the end. Our logic is that: this way, the init has time to be ''read'' by te robot before we ask about the variable (In our mind the init should be done before the before start anyway, but it does not appear to be the case). On most projects, we do it this way and don't have problems. But on those 2 robots it was inneficient. We think (we can't really prove it) that tracking program and thread execution makes it worse, so we try to limit that to a minimum in all our projects.
Additionnal info that might be special in the programs:
Both robots have about 10 threads in them to communicate to, activate or monitor differents machines surrounding them or to choose the right movements for the robot depending on the next piece to take.
Both robot have about 10 subprograms and the main is essentially a list of subprogram calls. ( we have made robot with more threads and more subprograms that do not have this problem)
Both robot use a lot of modbus communication, on one of them we litterally hit the limit number or register/Digital IO that we can add in the installation. This is about 50 total, maybe 10 registers and 40 digital IO. The other one might have about 20. There are about 5 device that are on the modbus network. (this was the first time we maxed out the modbus)
Has any of you ever got this problem / found the solution?