does the engine send an ACK/NAK after receiving a command ?
It would help a lot if it did.
Do I get it right, for example if I want to send a motor home, I send
1 // program control
2 // 2 data bytes
7 //send the motor home
2 // for Motor #2
(I assume I send it like 1272, without the line breaks?)
If I do this, nothing happens. I am not sure, if the problem is between my computer and the openmoco engine or the between the engine and the stepper controller. For this, a reference whether or not the engine got a valid command would be very helpful.
The serial connection is not the problem, since it always displays "Running" in the terminal window.
Great work anyway, thank you for sharing !
Submitted by shutterdrone on Tue, 12/15/2009 - 19:05.
Matt, actually the protocol is a binary protocol, so you cannot send ascii characters to it (unless you know the byte values for each position, and represent it with an ascii character of the same byte value).
It doesn't yet acknowledge commands, the next version will (currently in development).
So, to look at what you'd send for that...
(using 'man ascii'):
<soh><stx><bel><stx>
Obviously, that'd be difficult to type, but it's even more difficult to send lots of data converting ascii back into numeric values, for example, consider telling the motor to move 65,535 steps (maximum amount for the 'move now' command), as ascii representing numeric values:
1862165535, or 10 bytes, whereas using the binary protocol, it takes only 6 total bytes, and very little code (just some bit-shifting) to process.
So, the trick is to look at it as a binary protocol, and then you'd want to construct just the exact values you mean, using a big-endian strategy. There is some more talk about it in an older forum post here, that talks about the strategy: python interface
If you want to do a quick test, the slim textual interface allows you to send commands (it uses the perl API) analogous to the API commands, e.g.:
[1]> home 2
The slim interface can be downloaded from here: SLIM in SVN, it also requires the perl API. I apologize for not having it fully documented yet here, but alas, I'm afraid that for the vast majority of people asking for documentation, they're expecting a "textual" protocol that they can just enter via a terminal emulator. While it would easier to play with, it would reduce the available functionality and take a hit on both performance and memory (for example, the doubling of the serial buffer needed would take away valuable memory from keyframes, actions, etc.).
Thank you for your answer. I was tricked into believing the commands to be ASCII since the Arduino sends the "Running" line in ASCII. I use Bray's Terminal in a Virtual Box running Windows on a Macbook Pro and communication works great now, I just have to get used to the protocol...
ACK/NAK
HI,
does the engine send an ACK/NAK after receiving a command ?
It would help a lot if it did.
Do I get it right, for example if I want to send a motor home, I send
1 // program control
2 // 2 data bytes
7 //send the motor home
2 // for Motor #2
(I assume I send it like 1272, without the line breaks?)
If I do this, nothing happens. I am not sure, if the problem is between my computer and the openmoco engine or the between the engine and the stepper controller. For this, a reference whether or not the engine got a valid command would be very helpful.
The serial connection is not the problem, since it always displays "Running" in the terminal window.
Great work anyway, thank you for sharing !
Matt, actually the protocol
Matt, actually the protocol is a binary protocol, so you cannot send ascii characters to it (unless you know the byte values for each position, and represent it with an ascii character of the same byte value).
It doesn't yet acknowledge commands, the next version will (currently in development).
So, to look at what you'd send for that...
(using 'man ascii'):
<soh><stx><bel><stx>
Obviously, that'd be difficult to type, but it's even more difficult to send lots of data converting ascii back into numeric values, for example, consider telling the motor to move 65,535 steps (maximum amount for the 'move now' command), as ascii representing numeric values:
1862165535, or 10 bytes, whereas using the binary protocol, it takes only 6 total bytes, and very little code (just some bit-shifting) to process.
So, the trick is to look at it as a binary protocol, and then you'd want to construct just the exact values you mean, using a big-endian strategy. There is some more talk about it in an older forum post here, that talks about the strategy: python interface
If you want to do a quick test, the slim textual interface allows you to send commands (it uses the perl API) analogous to the API commands, e.g.:
[1]> home 2
The slim interface can be downloaded from here: SLIM in SVN, it also requires the perl API. I apologize for not having it fully documented yet here, but alas, I'm afraid that for the vast majority of people asking for documentation, they're expecting a "textual" protocol that they can just enter via a terminal emulator. While it would easier to play with, it would reduce the available functionality and take a hit on both performance and memory (for example, the doubling of the serial buffer needed would take away valuable memory from keyframes, actions, etc.).
!c
Ascii
Hi,
Thank you for your answer. I was tricked into believing the commands to be ASCII since the Arduino sends the "Running" line in ASCII. I use Bray's Terminal in a Virtual Box running Windows on a Macbook Pro and communication works great now, I just have to get used to the protocol...
The ready line
Sorry Matt, that was a debugging print that got left in there. Version 0.82 (in svn) removes this, and also implements bi-directional communication.