Hey all,
Weird problem here. Any help greatly appreciated.
Here's the setup:
3 X SM2315 motors on an RS-232 daisy chain on COM1
Port is at 9600,8,n,1,n, default FIFO buffers (although I've tried adjustments to no effect)
Motors are 2 X 4.40 and 1 X 4.40C
All motors loaded with "End" program only (verified)
Using SMI 2.4.3.2 (but have also tried earlier rev's without success)
Computer is running WinXP SP3
The problem: I can't get SMI to detect/address the motors.
The weird part:
I CAN communicate with the motors just fine using the Terminal. Via the Terminal I can read parameters, put them to sleep and wake them, upload and transmit programs, and manually address the chain. I seem to be able to do everything you can normally do via ASCII commands through the terminal.
I also have a custom-written windows application that controls the motors. This application addresses the motors, sets their PID parameters, and allows for both manual and automatic control of all three axis in the system via ASCII commands over the RS-232. This program communicates with, addresses, and controls the motors just fine. I have verify this by running the custom application and then using SMI Terminal to confirm the chain addressing and PID settings. The custom app is clearly talking to the motors without problem.
When I ask SMI to find/detect/address the chain, however, it comes back as no motors found. The RS-232 channel is in there and it's at the correct settings and I can see the ASCII commands going out from SMI using the sniffer. The motors, though, never respond.
Trying to detect the motors also locks up the comm on the chain. If I issue a detect/address from SMI all three motors become unresponsive to any further commands and need to be power cycled before I can talk to them again. Even the comm lockup wizard won't get them back. They have to be powered off before I can talk to them again.
The tuning application also won't work even if I manually address the motors first. The app starts to run and tries to transmit the tuning program to the selected motor but then freezes and comes back with a "No Response Received" error before crashing.
This one has me stumped. There seems to be no issues with the port, the comm hardware or the power supply as I can talk to the motors via Terminal and my custom application just fine. It's only when I try to let SMI communicate with them that things go haywire. I've tried backing out and re-installing SMI, switched to an earlier version, tested all the comm connections, monkeyed with the port settings, etc, etc, etc, and still can't find anything obviously amiss. I'm now officially out of ideas.
Has anybody seen anything like this before? I need to get SMI talking to the motors so I can check/adjust the tuning. Any suggestions very much welcomed.
Thanks and Cheers!
Big Box.
I haven't seen a problem like this. The usual steps for flaky communications are...
Check the Advanced Settings in Device Manager... Port Settings Tab. Make sure the FIFO buffers for that port are at the lowest setting.
Make sure you don't have something like RSLinx running that conflicts with the SMI software.
Thanks Csearcy.
I've tried to adjust the port parameters without success. Lowering/turning off FIFO buffering has no effect.
The system should also be free from any software that would interfere with serial comm. The computer is dedicated to the device that includes the motors. It has a clean install of XP with just our custom app and SMI on it.
We've got over 40 of these exact setups in the field with installs going back more than 15 years. I've never seen one do this before.
What bothers me is that the comm locks up when I try to detect the chain. That suggests to me that the first motor is freezing up and not echoing commands after SMI tries to detect it. I am, of course, working on a system that's 5000 miles from home base so I don't have another motor on hand that I can swap out. I haven't tried isolating the motors and communicating with the individually but will do so to see if there's one in the chain that's causing the problem.
I also note that the detect/address function cycles through commands pretty fast when it's scanning the chain. Do you know if there's there a way to slow that down? I'm thinking that one of the motors may have gotten sluggish and is responding too slowly for SMI to hear it before the software moves on to scan the next baud setting.
The original tuning on this system was done several years ago using a much earlier version of SMI. I'm having home base email me an image of an older version install disc (1.x) and will see if I can get the motors talking to that older version.
It's a strange one though. I'm certainly at a loss.
Thanks for your help. Please let me know if you think of anything else. I'll let the board know if I discover the root of the evil.
Cheers,
Big Box.
Update on the situation:
I rolled back SMI to v1.22 and it instantly cured the problem. The older version was able to detect, address, and run the tuning app on the chain with no issues. Tuning isn't quite as fun with v1.22 as it is with v2.x, but we got through it.
I have no clue why this particular installation didn't like SMI v2.x but the tuning is done, the system is running smooth, and I'm catching a flight back home tomorrow. At this point I'm just going to keep a copy of v1.22 on my laptop and only worry about it if happens again.
Thanks to Csearcy for the suggestions. I guess this one just gets put into the "X-Files" folder for now.
Cheers,
Big Box.
Great Information.Thanks for sharing