Hi,
I'm using three SV23165DT-BRK, firmware 5.0.3.45 with a custom java application. I communicate with the motors through a device that is an IP to rs232 gateway (netcom 413) at 57600bps, because there is long distance between the motors and the computer.
I have a procedure stored on the motor that returns some information:
C10 ' returns useful data for all modes
PRINT("INFO",#13,#10)
RTEMP
RAT
RDT
RMODE
RPA
RPT
RVA
RVT
RTRQ
RT
RW(0)
RW(1)
RW(2)
RW(3)
PRINT("EOT",#13,#10)
RETURN
It works well, but on some circumstances, the motor stops running the subroutine. Sending single commands such as RPI still gives an answer.
What I think happens is: I aggressively (well, every 100ms, not that fast) call GOSUB(10), and it seems to sometime fail to complete until the next call. Then the motor would stop running the C10 procedure, until I issue an END command. It then works again.
I captured a whole work session at the network level with wireshark and it is clear the motor stops answering only to the GOSUB(10) command. MT=xxx still work.
While I understand I'm not gentle with the motor, it for sure looks like a bug (stack overflow ?).
To add to the problem, I once did a watchdog procedure running on the smartmotor. It sometimes stopped running, supposedly for the same reason. So I dropped the watchdog and reduced the security of my system. I'm unhappy about that.
Workarounds I found:
- drop the C10 procedure and issue individual commands instead (that's only 10% of my bandwidth after all)
- issue "END GOSUB(10)" to return the motor to a known state before every C10 call. However, that would prevent me to implement an infinite loop for a watchdog or for using interrupts.
Is that issue known ? What can you suggest ?
Thanks for reading,
Charles
Hi Charles,
The stack is only 10 deep before you get a stack overflow... so that is probably what you are having.
A possible work around would be to set a variable or user bit when you call the subroutine... and then let the subroutine clear it... as a condition before it can be called again. This would allow the call to be event driven... instead of timed.
Hi,
thank you for your answer.
I timed the execution and see that the round-trip time between question and answer is 10-30ms.
However I reduced the amount of data I query, and seem to be unable to reproduce the problem anymore.
However, I noticed two distinct situations:
(1) the motors only fails to execute stored procedures (GOSUB), but still answers individual commands like RPI and PT=xxx.
(2) the motors stops communicating at all.
In situation (2), I tested like that:
- I somehow get the motor to hang while connected to the IP/RS232 gateway.
- I then unplug the rs232 from the IP gateway and plug it to a USB/RS232 adapter on my computer, without powering the motor off.
- I try with a serial terminal software to ask RPI, END, whatever, the motor keeps quiet.
- Then, I use SMI to autodetect the motors. According to the serial sniffer window, it tries to "WAKE WAKE ECHO" the motor at various baudrates. The motor seems to answer when the baudrate is 2400 (it's supposed to be 57600).
- So I tried to use my serial terminal software to do the same thing, to no avail.
The question is: is there a particular sequence that lets one reset the motor to factory defaults or failsafe mode ?
My aim is to be able to recover communications without having to power cycle the motor or launching SMI.
Thanks,
Charles
If the problem is caused by a Stack Overflow... and you can't find a way to prevent it.... you can pick some point in the program... and issue a STACK command. This is a "last resort" method.