I’ve been using the ur10e and have successfully been implementing programs using socket connecting in the ur script, dashboard server and modbus. The critical thing I need is the safety status most importantly if the robot is faulted. there is no way to do this with a script, in the dashboard server the connection fails when the robot faults and cannot connect until it is reset by the teach pendent. In modbus there is no bit or register listed that indicates the fault it says there is in the cb2 configuration but this is matching the cb3 configuration on the Excel document provided. Is there a revised document for e series? Why is the io not configurable to fire a digital output when the robot is faulted? This to me is very frustrating as I do not want to write a custom protocol to communicate with the rtde server or any of the primary or secondary client servers to get one bit. I don’t know why this was overlooked or if this is by design. I have applications where the teach pendent will not be easily accessible and the operators need to know if the robot is faulted to call certain people. Please someone give me some suggestions
By faulted do you mean protective stopped or a hard fault that stops the controller to where you had to restart the controller at the initialization screen? We use the dashboard server to get safety status, I believe it also shows faults when we have them but can’t recall. Here is a screenshot from our app showing the core data we get back from the dashboard server
Hey Matt, I’ve written something similar to the interface you’ve shown I’m a VB.net forms app, but yes I mean a hard fault like this
Dashboard server closes connection when this happens and cannot be reconnected unless this is cleared on the teach pendent. Now in talking about modbus, the Excel sheet provided on the ur website States that register 258 is the robot status, but I have a 10e,
and will be using a 5e on the next project I am doing. That register adheres to the cb3 and 3.1 config where disconnected = 0, Confirm Safety= 1, booting = 2, power off = 3, power on = 4, idle =5, backdrive = 6, running =7 which I’ve confirmed with my robot.
We have gotten the controller to crash by spamming the logs with textmsg(). It might take a couple of threads to make it happen as it needs to overwhelm the logs.
One idea, you could always place a single output to be high, don’t let it go low ever and use that to detect a fault. If the servers are shutting down the the IO should go off as well. You could then monitor this over RTDE in your app.
Ok thanks Matt I will try that to fault the robot. But in regards to my other questions, is there a modbus register for the e series that will inform me the robot it faulted? Why does the dashboard server disconnect when the robot faults. I’m am trying to not
use the rtde if I can. I have some c# code that was posted on the forum that works but I need to convert it to vb.net and the code is undocumented. Also, the documentation on the ur website pertaining to rtde does not explicitly explain how to structure the
communication.
I think it will just show powered off, that’s what we see in RTDE, not faulted. You won’t know why it’s powered off. The reason Dashboard shuts off is the controller has stopped running and the server is on the controller.
How often are you seeing faults? It’s rare that we see a fault unless there is a real problem. You could always just hardwire a light where the operators are that either turn off on a fault or use a relay and flip the logic to turn the light on when the output goes off.
Matthew Bush
Hirebotics
M: (615) 479-6151
Hey Matt I’ve seen, like 3 faults in the month and a half I’ve been using this robot and I’ve been using it essentially everyday for 8 hrs. They always have cleared on restarting the bot, and it has nothing to do with what I’m doin motionwise. I am probably
stressing the controller a little with all the experimentation I’ve been doing writing the code to interface the robot with a pc, so I’m not worried at all about that. I am thinking of writing a routine that just sets a digital high and watches it through
modbus so if that ever goes low I know it has faulted kinda like a heart beat, if like you say all the io will shut down in a fault condition. I also tried your suggestion of trying to flood the logs with about 50 threads on continuous loops sending text msgs
but all it does is protective stop itself. I really need a way to fault it to test my programs heartbeat function without hurting anything. Our office internet is down today but will probably post on the forum that question Monday. Thanks for your quick responses
I appreciate it as well
Adam