How long should the following commands take? I’m seeing 0.55 secs with a LSS-ST1. I doubled the baud rate from default and it’s about the same. Consistently about 0.11 secs per get command.
Lynxmotion (LSS) - Adapter Board, 6A power supply, windows PC over USB.
pos = myLSS.getPosition()
rpm= myLSS.getSpeedRPM()
curr = myLSS.getCurrent()
volt = myLSS.getVoltage()
temp = myLSS.getTemperature()Hi @part_timer!
Ok, so lets gets some details clear first and then to an answer and solution! 
Not long at all, actually. At least one command is replied to per main loop, which on average are at most 1 ms. Therefore, the processing time for commands is pretty low (µs). The transfer rate of the reply is directly linked to the baud rate, of course. For example, a reply of *0QD300\r has 8 characters and would take about ((1/(baud rate / 10)) x 8) s to send, or about ((1 / (115200 / 10)) x 8) = 1.0850694e-5 s => 694.4 µs.
If you want more details on how long the entire process takes (sending, processing, replying), please have a look at this post. I go in details about the protocol and how it is handled and that includes logic analyzer screenshots of actual communication with a PC (USB) through a LSS Adapter Board and a LSS.
As you can read in the topic linked to above, many things can get in the way of obtaining a response. Most likely the size of the data payload and hardware FIFO are most likely responsible for the delays you see (combined with drivers, OS, etc.). On Windows 7 & 10 I’ve routinely seen ~15 ms (or 0.015 s) delays and sometimes up-to ~100 ms, depending on what else is happening simultaneously (and, of course, sometimes much higher but those are quite rare/abnormal).
I hope this info helps. Let me know if you have more questions!
Sincerely,
I assume you are using our LSS Python library? Please note that aside from all the delays added by a modern, not real-time OS and its hardware, there are also these facts to consider:
Ah, I thought the LSS Python library was vetted.
I found the problem, it is in the data = LSS.bus.read_until(lssc.LSS_CommandEnd). I should have been read_until(b’\r’). With that change it eliminates the serial timeout block.
@part_timer Another welcome to the RobotShop Community! Happy that issue is resolved. If you have feedback / suggestions / comments about the servos, we’re all ears. We hope you might also post what you create if it’s not confidential.
Well, it was vetted in the sense that it worked for all the major use cases at the time we tried it. Since Python is an interpreted language available on many more platforms and interpreters than would be reasonable to test, I fully expect this to be only one of many future things that can be improved about that library!
So, if I get this right, we should then update this line to use the b prefix in the constant definition?
Thanks for the help and I hope your project goes well!