[WR84]

Hello Everyone,

Could anyone please help us with the issues we're having with our Omron TM5-900 and control via IP?

We can create and simulate programs and follow curved paths fine, but when we try to run the program on the real robot, it sends an error message during the first movement.
It will get to the position of the first target, but will not go any further.

Clicking "Show Log" gives the following info:

Code:

Driver for RoboDK 5.7.4.24387
Disconnected
Stopped
Starting robot driver: C:/RoboDK/api/robot/TMDriver.py
Using RoboDK RoboDK v5.7.4
Starting...
Not started
Sending command...
Using Python version: sys.version_info(major=3, minor=10, micro=10, releaselevel='final', serial=0)
RoboDK Driver: C:/RoboDK/api/robot
RoboDK Driver for Omron-Techman v1.5.3
Command CJNT_FALSE: Get joints modbus
Command POSXYZ: get position xyz and rot
Command TOOLXYZ: get tool position xyz and rot
Command DELTA_DH: get robot kinematic signature
Working...
Working...
Disconnected
Connecting to robot < IP address removed - but the connection is fine >
Connecting...
Connecting...
Flow is in Listen mode: Listen1
Waiting for welcome message...
Ready
Sending command...
Working...
Unexpected error: Traceback (most recent call last):
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 34, in <module>
Unexpected error: RunMain()
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 1133, in RunMain
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 719, in RunDriver
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 785, in RunCommand
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 481, in WaitRobotMotion
Unexpected error: File "C:\RoboDK\api\robot\TMDriver.py", line 621, in print_joints
Unexpected error: TypeError: 'NoneType' object is not iterable
Stopped

Thanks in advance for any help given,

Best Regards,

Will

[Albert]

Can you provide the RoboDK project file with the program that is giving you issues? It will help us better understand this issue.

[WR84]

Hi Albert,

I've attached the program as requested, all of our programs behave the same way though, it doesn't matter how simple or complex the program is, whether it's just 2 targets or more, it always fails to do more than one movement.

To test when the fault log is sent, I programmed a long slow movement and as soon as the command is sent, the robot starts moving and it immediately sends the above fault to the log.

In searching the Forum I have seen other people coming up against the same problem, but there seems to be no solution. 
Since we have to demonstrate this system tomorrow, I'm now wondering if this problem is fixable? or is this just the limit of what the educational software licence will allow us to do? and are we wasting our time in trying?

Many Thanks,

Will

[Albert]

I noticed you changed the first movement from a Joint movement to a linear movement. This is important to properly establish the same robot configuration used in the simulation (same axes position).

Does it work if you try running the program on the robot with the default program generated by your curve follow project?
Does it work if you generate a program and load it on your robot controller?

[WR84]

I noticed you changed the first movement from a Joint movement to a linear movement. This is important to properly establish the same robot configuration used in the simulation (same axes position).

Does it work if you try running the program on the robot with the default program generated by your curve follow project?
Does it work if you generate a program and load it on your robot controller?

No it doesn't help if we try the default program ( we wouldn't have had to change it if it worked ), the linear movement is just a recent change after trying everything else I can think of, we've had hundreds of failed attempts to get this to work. The driver seems to be the problem.

I can now run the program (Zip) from a USB stick in the controller, it follows the whole path, but it's very slow.

We need to use remote control Via IP for our project though, so the real Robot's movements are matched by the RoboDK simulation in real time

---

Hi Albert, we now have the attached program working if we put it onto a USB stick, but it will still only go to the first position if we run the program via IP.

Could it be our IP settings are somehow wrong? 
Rather than the driver errors that were being told about by the fault log.
It seems to be that the PC can talk to the Robot, but the Robot can't reply to the PC.

[Albert]

I believe the main problem with your partially working connection with Omron TM robots is that you should connect the robot to the Ethernet port with Modbus access. Only one of the 2 or more physical Ethernet ports (RJ45) in the robot controller have this capability.

Let me know if this solves the problem.

Does it work if you try to get the joint values?
Does it work if you change all movement to joint moves?

I assume you followed these steps to place the robot in a listen mode so you can use the driver:
https://robodk.com/doc/en/Robots-Omron-T...-StartProg

[WR84]

I believe the main problem with your partially working connection with Omron TM robots is that you should connect the robot to the Ethernet port with Modbus access. Only one of the 2 or more physical Ethernet ports (RJ45) in the robot controller have this capability.

Let me know if this solves the problem.

Does it work if you try to get the joint values?
Does it work if you change all movement to joint moves?

I assume you followed these steps to place the robot in a listen mode so you can use the driver:
https://robodk.com/doc/en/Robots-Omron-T...-StartProg

Hi Albert,
              Thanks for the advice, a long time ago we were trying to use the wrong RJ45 port, but that's no longer a problem.

We have eventually solved this issue though, thanks to some help from google and my colleague Keith, a Doctor of Computer Sciences, who was unavailable until yesterday.

The Driver was the problem, I found a new driver online, but it still didn't work, so we fixed the broken driver in Notepad++ and it finally works as it should do.

The latest version of RoboDK was installed a few days before I posted, but the supplied driver 'TMDriver.py' is practically an empty vessel (2KB)

I downloaded the newer (40KB) driver from here: RoboDK Shared Files
But it gave the error message:
" Unexpected error: ModuleNotFoundError: No module named 'pymodbus.client.sync ' "

Keith Opened the Driver in Notepad++, did a search for: pymodbus.client.sync
and replaced all instances with: pymodbus.client

And it now works!  -  The updated Driver is attached.

We can now create a RoboDK program moving between several targets, simulate it, then tick: 'Run on Robot'  and 'Run' and the real robot will complete the whole program.

This is after months of going around in circles, trying to use RoboDK, getting stuck, trying to fix it, thinking our IP settings were wrong, giving up and using Matlab (or the truly awful TM_Flow software), getting what we needed just about done, before trying RoboDK again.

Which begs the Question, why does the latest version of RoboDK still ship with useless drivers?
I found a helpful video from 3 years ago saying that this was a problem and yet nothing has changed.
My boss was ready to give up on RoboDK entirely and cancel all of our licences, but now that it works, I might be able to convince him to keep them, mostly for the VR and (sort-of) AR potential that it has.

Hopefully the rest of this current project goes well and we don't run into any more similar issues.

And hopefully this info helps others who are struggling with the same issue as us in the future.

[Albert]

Thank you very much for your feedback and reporting your improvements!

We are looking into it and we'll merge your improvements with our most recent edits. We'll keep you posted.

[Phillip]

My best guess as to what happened in your setup is that your python environment somehow ended up with 2 versions of pymodbus installed simultaneously. This is not ideal and we'll improve the installer to make this not possible in the future. Sorry you had to go through this pain and dig up an old version through random forum discussion.

Now for the driver stub being 2kb, we provide compiled pyc versions for a variety of python versions. As such the py file you see is merely verifies the python version it's running on and then loads the appropriate version for the python version. Also, the version of the driver you linked isn't actually the latest that ships with RoboDK (1.5.3 and 1.6.0 made changes to fix use via the API and provide better error messages in the console)

Now for some nuance on pymodbus.client vs pymodbus.client.sync, when we developed the driver the latest version of pymodbus 2.5.3 with python 3.7 and used the "pymodbus.client.sync" at some point we updated to python 3 which in turn mean the latest version of the library was 3.0.2 and used the "pymodbus.client" syntax, the driver broke, we promptly fixed the driver as you can see in the changelog for "RoboDK v5.6.4 (2023-09-27)" (code change was made even earlier, just waited for the majority of users to be on python 3.10).

Now for the real problem which RoboDK could stand to improve is that if we shift a higher version of a default package, like pymodbus, the installer didn't delete the older version, we could stand to add an explicit delete list to an installer to prevent issues like this, the reason we don't delete things on upgrade is that we generally overwrite previous versions of drivers/posts and we don't want to delete custom user content, ie custom posts/drivers/stations/etc
In addition, we also now always freeze python module dependencies to a specific known good version and never take the latest.

Now for the record, the new code now 2.6.1 that will ship with the next version of RoboDK will have a switch to also support old pymodbus versions, but this isn't a situation we run into very often as we try and have minimal external dependencies

New import code as of driver version 2.6.1:

Code:

            if str(pymodbus.__version__).startswith("2."):
                from pymodbus.client.sync import ModbusTcpClient
            else:
                from pymodbus.client import ModbusTcpClient

Finally, to answer your question about how we avoid this happening, though these checks wern't sufficient for detecting this particular issue:
We try to ship the latest tested version of each driver with RoboDK by default alongside their accompanying libraries and environment requirements. Where applicable we use the OEM's IDE/Simulator to test against a variety of robot firmware versions. TM has no such software available, so we use packet capture and playback packs against the driver to test functionality doesn't break. This obviously doesn't save us against controller intricacies and differences between controller versions, sometimes we test with customers remotely as well, the version shipped with RoboDK was tested with a customer who demonstrated that it didn't work previously and by the end of the support session it worked.

Now once again, thank you for your valuable feedback and my apologies, in the future we'll write code in such a way that it has fallbacks for if old versions of the module end up being loaded.