Software version issues
Software version issues
I have a 7A RoboClaw with f/w 4.1.16. I have been using the Ion Motion Setup software version 1.6.6 which works fine with this unit. I recently went to try installing the software on another PC and it automatically updated to 1.0.0.45 which seems like an older version number, but appears to be a newer software. My RoboClaw board does not show up in this version at all. My other concern is that my application does not work with f/w 4.1.19, so I don't want to have to upgrade my f/w for this new version of software. Is there a place I can download and install older versions of the Ion Motion Setup software?
-
Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Software version issues
The internal update number(eg 1.0.0.45 in this case) isnt the same number as the software version number in the about box window. The previous version 1.6.6 had an update number of 1.0.0.44.
If you previously had 1.6.6 install on the PC and then updated to 1.7+ you can revert to 1.6.6 using Programs and Features in Microsofts control panel. Select uninstall/change and then use the window that opens to revert to the previous version.
However on a new install since 1.6.6 was never installed before I dont beleive you can revert to it. Before we try to figure out how to do that lets see if we cant get your problem fixed.
What is your application and how doesnt it work with 4.1.19 firwmare? Are you just concerned it wont work or have you tested it and found some function that isnt working for you?
When you say the board "does not show up" in the new version of IonMotion does anything show up?
What version of Windows are you using?
What hardware version of the Roboclaw are you using?
Did you test the new IonMotion version on the same computer as you used 1.6.6 on to determine it could not find the Robcolaw? If the Roboclaw is detected by 1.6.6 on that computer it should be found with 1.7+ software as well so I very much would like to be sure I understand what is happening.
If you previously had 1.6.6 install on the PC and then updated to 1.7+ you can revert to 1.6.6 using Programs and Features in Microsofts control panel. Select uninstall/change and then use the window that opens to revert to the previous version.
However on a new install since 1.6.6 was never installed before I dont beleive you can revert to it. Before we try to figure out how to do that lets see if we cant get your problem fixed.
What is your application and how doesnt it work with 4.1.19 firwmare? Are you just concerned it wont work or have you tested it and found some function that isnt working for you?
When you say the board "does not show up" in the new version of IonMotion does anything show up?
What version of Windows are you using?
What hardware version of the Roboclaw are you using?
Did you test the new IonMotion version on the same computer as you used 1.6.6 on to determine it could not find the Robcolaw? If the Roboclaw is detected by 1.6.6 on that computer it should be found with 1.7+ software as well so I very much would like to be sure I understand what is happening.
Re: Software version issues
Version 1.7 makes more sense than 1.0.0.45. FYI 1.0.0.45 is what shows up when you click on Help...About in the V1.7 software. In 1.6.6 it shows up as V1.6.6.
I am trying to install the software on a Windows 7 machine. I am not sure of the hardware version of the RoboClaw as I don't have a machine I can connect to it with right now. The V1.7 software starts up just fine and shows the newer QA screen, but there is nothing under devices to connect to or firmware. I also tried this software on an XP computer that has V1.6.6 and V1.7 won't work on this computer either. I had to revert back to 1.6.6. I haven't dug into possible USB issues yet because I have a feeling that if I did get V1.7 working it would require me to load f/w 4.1.19 which I don't want to do.
My application is a VB app that I have tested in V4.1.19 and it does not work properly. When I go back to V4.1.16 it works great. This is an issue we have emailed each other about and I have sent you my project, but we have never come to a resolution. Here is a thread from where it started:
http://forums.ionmc.com/viewtopic.php?f ... dback#p795
I am trying to install the software on a Windows 7 machine. I am not sure of the hardware version of the RoboClaw as I don't have a machine I can connect to it with right now. The V1.7 software starts up just fine and shows the newer QA screen, but there is nothing under devices to connect to or firmware. I also tried this software on an XP computer that has V1.6.6 and V1.7 won't work on this computer either. I had to revert back to 1.6.6. I haven't dug into possible USB issues yet because I have a feeling that if I did get V1.7 working it would require me to load f/w 4.1.19 which I don't want to do.
My application is a VB app that I have tested in V4.1.19 and it does not work properly. When I go back to V4.1.16 it works great. This is an issue we have emailed each other about and I have sent you my project, but we have never come to a resolution. Here is a thread from where it started:
http://forums.ionmc.com/viewtopic.php?f ... dback#p795
-
Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Software version issues
Sorry. My mistake. I just looked at the code and remember why it didnt go any further than that. The problem is your code is using a third party library we dont have(an ethernet bridge interface it appears).
Since I couldnt run the project I was planning on going through it manually to see if anything looked like the cause. Of course I got side tracked by something else and then promptly forgot about it. Its been sitting on my dekstop.
So I just went through it manually to see if anything popped and I've got a couple questions.
1. Where are the Enet strings coming from? Eg "10.10.4.59 - Rev2 (Hercules)". Are you able to assign a specific ID to each ethernet port/PLC port?
Is tmrUpdate_Tick the code that is reading the status information(eg encoders/current) that doesnt work when you run command 67?
Im assuming you are using the "Move to Position" button/settings to execute command 67? If so can you modify the code to use commands 65 amd 66? Does the same thing happen in regards to reading back status while the commands execute?
Is the RoboCmd call for command 67 waiting at the serverStream.Read call while the position movement is happening?
'Send the command through the serial port to the RoboClaw
serverStream.Write(w, 0, w.Length)
serverStream.Flush()
txtSend.Text = w(0) & ", " & w(1)
'Read the response through the serial port from the RoboClaw
serverStream.Read(r, 0, r.Length)
txtReceiveStr.Text = System.Text.ASCIIEncoding.ASCII.GetString(r)
If the problem is in the Roboclaw not acknowledging the command until the movement finished(it shouldnt but its something I wanted to check) this would be the place where the code would freeze up until it got the ack.
How are you preventing the RoboCmd calls in the tmrUpdate_tick function from interfering with the RoboCmd calls from button presses? Potentially without a mutex you could be calling RoboCmd from two threads at the same time and I dont see any method to prevent that from happening.
Since I couldnt run the project I was planning on going through it manually to see if anything looked like the cause. Of course I got side tracked by something else and then promptly forgot about it. Its been sitting on my dekstop.
So I just went through it manually to see if anything popped and I've got a couple questions.
1. Where are the Enet strings coming from? Eg "10.10.4.59 - Rev2 (Hercules)". Are you able to assign a specific ID to each ethernet port/PLC port?
Is tmrUpdate_Tick the code that is reading the status information(eg encoders/current) that doesnt work when you run command 67?
Im assuming you are using the "Move to Position" button/settings to execute command 67? If so can you modify the code to use commands 65 amd 66? Does the same thing happen in regards to reading back status while the commands execute?
Is the RoboCmd call for command 67 waiting at the serverStream.Read call while the position movement is happening?
'Send the command through the serial port to the RoboClaw
serverStream.Write(w, 0, w.Length)
serverStream.Flush()
txtSend.Text = w(0) & ", " & w(1)
'Read the response through the serial port from the RoboClaw
serverStream.Read(r, 0, r.Length)
txtReceiveStr.Text = System.Text.ASCIIEncoding.ASCII.GetString(r)
If the problem is in the Roboclaw not acknowledging the command until the movement finished(it shouldnt but its something I wanted to check) this would be the place where the code would freeze up until it got the ack.
How are you preventing the RoboCmd calls in the tmrUpdate_tick function from interfering with the RoboCmd calls from button presses? Potentially without a mutex you could be calling RoboCmd from two threads at the same time and I dont see any method to prevent that from happening.
Re: Software version issues
1. All Ethernet strings are sent from the VB code to a wireless module that converts them to serial to talk to the RoboClaw.
2. Yes, the command 16, 17 and 49 that run under tmrUpdate_Tick stop updating when command 67 is run with f/w 4.1.19. Sometimes I will see one update happen, so maybe it isn't completely stopped, but just slowed down to the point of unusable. They update quickly without issue with f/w 4.1.16.
3. I have not tried commands 65 and 66. At this point further testing will be difficult in the short term as there are to many other things on this project that need attention.
4. Command 67 is not waiting at the serverstream.read call as the program doesn't seem to lock up when this happens. It just isn't updating values.
5. I don't have a method to stop tmrUpdate_tick from interfering with buttons other than verifying that I'm getting good data before sending it to the labels. This hasn't been a problem.
At this point I would really like to figure out what the problem is, but one of my bigger concerns due to having to work on other project issues is getting an install for Ion Motion V1.6.6. Is this something you can get me as a short term fix?
2. Yes, the command 16, 17 and 49 that run under tmrUpdate_Tick stop updating when command 67 is run with f/w 4.1.19. Sometimes I will see one update happen, so maybe it isn't completely stopped, but just slowed down to the point of unusable. They update quickly without issue with f/w 4.1.16.
3. I have not tried commands 65 and 66. At this point further testing will be difficult in the short term as there are to many other things on this project that need attention.
4. Command 67 is not waiting at the serverstream.read call as the program doesn't seem to lock up when this happens. It just isn't updating values.
5. I don't have a method to stop tmrUpdate_tick from interfering with buttons other than verifying that I'm getting good data before sending it to the labels. This hasn't been a problem.
At this point I would really like to figure out what the problem is, but one of my bigger concerns due to having to work on other project issues is getting an install for Ion Motion V1.6.6. Is this something you can get me as a short term fix?
-
Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Software version issues
First you must stop the timer thread from sending packet serial commands while you are sending packet serial commands from another thread. Period.
It was pure luck that 4.1.16 seemed to work for you. I suspect it failed quite a bit but you didnt notice it. A slight timing change or error correction change in 4.1.19 is probably why you are seeing it all the time now. But in either case you cant do what you are doing.
You may not be able to stop the timer thread function but you can setup a mutex so that while the 67 packet(or any other button command packet) is being sent you dont send any packet serial commands from the timer thread function. Just before you send packet serial commands from the buttons activate/set the mutex. Then once the packet serial command is sent you deactivate/clear it. Then in your timer function you add a conditional around the paacket serial commands that will skip them if your mutex is set.
Until you do this I have to assume this is a race condition between the two threads. After you have fixed this if the problem still happens we will continue to work with you but this is a major mistake when dealing with serial communications so it is most likely the cause of the problem.
It was pure luck that 4.1.16 seemed to work for you. I suspect it failed quite a bit but you didnt notice it. A slight timing change or error correction change in 4.1.19 is probably why you are seeing it all the time now. But in either case you cant do what you are doing.
You may not be able to stop the timer thread function but you can setup a mutex so that while the 67 packet(or any other button command packet) is being sent you dont send any packet serial commands from the timer thread function. Just before you send packet serial commands from the buttons activate/set the mutex. Then once the packet serial command is sent you deactivate/clear it. Then in your timer function you add a conditional around the paacket serial commands that will skip them if your mutex is set.
Until you do this I have to assume this is a race condition between the two threads. After you have fixed this if the problem still happens we will continue to work with you but this is a major mistake when dealing with serial communications so it is most likely the cause of the problem.
Re: Software version issues
What you are stating makes sense. It seems like if a command 67 request is made while it is halfway thru sending a request to get the amperage value I would just get garbage back and my checksum wouldn't add up. This would cause the amperage to not update in the form. I'm not sure why this would happen more for 4.1.19 and only for command 67, but I will try disabling the update timer when I am making a command request.
Re: Software version issues
Tried disabling the timer when sending a command to the RoboClaw and it works fine for V4.1.16. I still need to find time to update to V4.1.19 and test it there.
Also, back to the software issue. Do you have a download site to get past versions of Ion Motion software? Even if I get this running perfect in V4.1.19 we can't update the firmware every time someone wants to connect to it with a new PC and there has been a software upgrade. This could cause maintenance nightmares as the parameters get wiped when the f/w is updated and these RoboClaw boards are running on a machine that will run 24 hours.
Also, back to the software issue. Do you have a download site to get past versions of Ion Motion software? Even if I get this running perfect in V4.1.19 we can't update the firmware every time someone wants to connect to it with a new PC and there has been a software upgrade. This could cause maintenance nightmares as the parameters get wiped when the f/w is updated and these RoboClaw boards are running on a machine that will run 24 hours.
-
Basicmicro Support
- Posts: 1594
- Joined: Thu Feb 26, 2015 9:45 pm
Re: Software version issues
Starting with 4.1.19 you will be able to keep the older version of the software that was already installed(at least one previous version anyway).
As for directly using the older versions I havent figured that out yet. The data is still on the server but the way Microsoft's ClickOnce installers work doesnt seem to give any option to allow installing the older versions directly.
I am still looking into it.
As for directly using the older versions I havent figured that out yet. The data is still on the server but the way Microsoft's ClickOnce installers work doesnt seem to give any option to allow installing the older versions directly.
I am still looking into it.
Re: Software version issues
Did you guys ever come up with a method to download and use older versions of your software? I wanted to see if I could install the newest software that works with firmware V4.1.16.