EBB command comments

[bsdphk]

I just got my Axidraw, and since I'll be writing my own software, I started at the EBB Command Set page (http://evil-mad.github.io/EggBot/ebb.html) Here are some comments based on that:

1. It would be useful if the QM command (or a new QF?) command would report if the FIFO slot was full.

2. It suprised me a little bit that the the AxiDraw had reversed default pen-state, so that Reset lowers the pen. Unless some kind of persistent configuration exists, I guess that's just the way it works ?

3. Maybe add under SM which products should use XM instead ?

4. QN says that the node count will be updated by SM commands. It is neither incremented by SM nor XM commands as far as I can tell.

5. Does NI and ND go through the FIFO ?

6. Should SP and TP also increment the node counter ?

7. In fact, how about noting for all commands if it goes through the FIFO and if it updates the node count ?

[oskay]

I'll let @EmbeddedMan comment on the others, but:

[2.] While there is conversationally a "pen up" and "pen down", either may be set higher or lower than the other. In normal use, the stepper motors are energized and the pen heights are set before beginning plots. The state at reset (while consistent) should generally be considered as "undefined," with respect to those two user-defined positions.

It might be worth revisiting what the default position is at turn-on. However, caution should be exercised: some machines using the EBB do not physically permit the full range of servo positions.

[3.] There is not a fixed list of "products" that should use XM. The EBB can be used with a wide variety of machines and configurations.

[6.] I expect not.

[7.] Adding a note to each command about whether it is executed immediately or added to the motion queue is a very good idea.

[EmbeddedMan]

[1] Yes! i Think that's a great idea. I will add another output value to QM
that will list the status of the FIFO.

[2], [3], Windell covered this perfectly

[4] You are correct. The documentation is wrong - the node counter is not
touched by any motion control commands.

But a bigger question is - should it be? I know we originally indented it
to count the number of moves. Is it being used for that at this time by any
software? If there's a need to count moves, we could do what the
documentation says, but I don't want to break anybody's code.

[5] They do not.

[6] I guess it depends on exactly what we want the node counter to really
count. My guess is that nobody is using it at present.

[7] Agreed - I will add to the docs.

Thank you so much for your awesome feedback! We love users like you that
dive into the details and help make the EBB even better-

*Brian

On Tue, Nov 15, 2016 at 3:25 AM, Windell Oskay notifications@github.com
wrote:

I'll let @EmbeddedMan https://github.com/EmbeddedMan comment on the
others, but:

[2.] While there is conversationally a "pen up" and "pen down", either may
be set higher or lower than the other. In normal use, the stepper motors
are energized and the pen heights are set before beginning plots. The state
at reset (while consistent) should generally be considered as "undefined,"
with respect to those two user-defined positions.

It might be worth revisiting what the default position is at turn-on.
However, caution should be exercised: some machines using the EBB do not
physically permit the full range of servo positions.

[3.] There is not a fixed list of "products" that should use XM. The EBB
can be used with a wide variety of machines and configurations.

[6.] I expect not.

[7.] Adding a note to each command about whether it is executed
immediately or added to the motion queue is a very good idea.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#63 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAbeCEkY3ObhtwypjBRGyKcWnj38_VLiks5q-XqlgaJpZM4KyRNa
.

[EmbeddedMan]

PR #66 now has a chance for [7]. Once we agree what changes should be made for [4], I will update the code and/or documentation as well. Any thoughts?

[oskay]

IIRC (it has been a while!), the original intent of the node counter was to provide an on-board means of storing the progress through the plot, which could be "hand controlled" by sending commands to it. In that sense, it is better if the SM/XM/AM/Whatever commands do not alter the value. I would advocate changing the documentation, not the code-- especially now with the addition of the QS/CS commands.

[EmbeddedMan]

The only problem I can think of with this approach is if the PC application
is counting on the node count being accurate while moves are still going
on. Since the node count commands are not put through the motion queue, you
could send a couple long move commands and then send two node increment
commands, and the node count would get updated before the moves finished.

However, it would take a pretty sophisticated PC app to use the node
counter in this way.

Also, if we change the behavior of the node count commands, any existing
apps that rely upon those commands may not work properly.

Thus I agree that the right course of action right now is to just update
the documentation to match what's in the code. Although the node counter
may not be quite as useful as it otherwise could be, I think at this point
this approach is the right one.

*Brian

On Wed, Nov 16, 2016 at 11:56 AM, Windell Oskay notifications@github.com
wrote:

IIRC (it has been a while!), the original intent of the node counter
was to provide an on-board means of storing the progress through the plot,
which could be "hand controlled" by sending commands to it. In that sense,
it is better if the SM/XM/AM/Whatever commands do not alter the value.
I would advocate changing the documentation, not the code-- especially now
with the addition of the QS/CS commands.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#63 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAbeCBl55w8VttT_OVI72ijfup_E8Z1Aks5q-0PPgaJpZM4KyRNa
.

[EmbeddedMan]

bsdphk - I have just uploaded a new (v2.4.4) EBB firmware version that implements the new QM command value. There are now four values printed out on the QM command, where the fourth one is the status of the FIFO (0 = FIFO empty, non-zero = FIFO not empty).

Here's a link to the new hex file : https://github.com/evil-mad/EggBot/raw/master/EBB_firmware/Releases/app/EBF_v244/EBV_v244.hex

I'll have the documentation updated in a couple days. Give it a try and tell me what you think.

[EmbeddedMan]

Poul-Henning

OK, the latest version of the EBB Command document should have all of the
changes we've agreed to here. The latest version of the EBB firmware
supports the extra QM FIFO status, and the docs have listed if they are put
in the motion queue or not.

Please let us know if we missed anything, or if you need help updating to
the latest firmware version.

If we don't hear back from you, we'll assume all is well and this issue
will be closed. Thanks for the great feedback!

On Wed, Nov 16, 2016 at 12:09 PM, Brian Schmalz brian@schmalzhaus.com
wrote:

The only problem I can think of with this approach is if the PC
application is counting on the node count being accurate while moves are
still going on. Since the node count commands are not put through the
motion queue, you could send a couple long move commands and then send two
node increment commands, and the node count would get updated before the
moves finished.

However, it would take a pretty sophisticated PC app to use the node
counter in this way.

Also, if we change the behavior of the node count commands, any existing
apps that rely upon those commands may not work properly.

Thus I agree that the right course of action right now is to just update
the documentation to match what's in the code. Although the node counter
may not be quite as useful as it otherwise could be, I think at this point
this approach is the right one.

*Brian

On Wed, Nov 16, 2016 at 11:56 AM, Windell Oskay notifications@github.com
wrote:

IIRC (it has been a while!), the original intent of the node counter
was to provide an on-board means of storing the progress through the plot,
which could be "hand controlled" by sending commands to it. In that sense,
it is better if the SM/XM/AM/Whatever commands do not alter the value.
I would advocate changing the documentation, not the code-- especially now
with the addition of the QS/CS commands.

—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
#63 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAbeCBl55w8VttT_OVI72ijfup_E8Z1Aks5q-0PPgaJpZM4KyRNa
.

[bsdphk]

Sorry for not keeping up, this is just a "as time permits" sparetime project for me.

I'll try to test the new firmware this weekend.

With respect to point 3: Yes, I realize that this is a general purpose board, but a lot of people will encounter it first on the EggBot or AxiDraw, and therefore adding a small not "Don't use SM for the AxiDraw, use XM instead." would have saved me a couple of very confused minutes.

About the node counter: I'm not sure I ever understood what the purpose was, I merely observed that it did not work the way the documentation said it would.

About the FIFO in general: Is it the intent that the computer tries to just keep the FIFO slot filled, or is it considered OK to blast commands at the EBB and rely on USBs flow-control ?

In the first case, it might be an idea if the EBB could send a token to the computer when the FIFO empties, so that the interaction could be:

    Computer     EBB
    cmd1 ->      (starts cmd1)
    cmd2 ->      (goes into fifo)
    (wait for msg from EBB)
                 (cmd1 completes, cmd2 taken from fifo)
                 <- fifo empty
    cmd3 ->      (goes into fifo)
    (wait for msg from EBB)
                 (cmd2 completes, cmd3 taken from fifo)
                 <- fifo empty
    cmd4 ->
    (wait for msg from EBB)
                 (cmd3 completes, cmd4 taken from fifo)
                 <- fifo empty
    (poll with QM until cmd4 motion stops)

Alternatively one could do an optional flag on the motion commands that says "Send me a notice when this motion starts"

[EmbeddedMan]

I'll add your comment about using XM for AxiDraw to the EBB command document - I don't see that it could hurt. About the FIFO: It's up to the PC software how, exactly, you want to use it. Both methods you mention are valid. The good thing about always keeping the FIFO full and letting the USB flow control block the PC side when the EBB is busy is that you have much less risk of an underflow issue on the EBB side, since you'll have those extra commands buffered up (in the FIFO and in USB). The downside is that you won't be able to send any new commands while USB is blocking, waiting for the currently executing command to finish on the EBB side. So this prevents you from doing emergency stops, or reading digital or analog levels, controlling servos, etc. in an immediate manner. Now, one way to get around this is to break apart all of your long moves into short segments. The Sisyphus project does this - it makes every move 100ms long, and thus is always feeding the EBB new motion commands at a 10Hz rate, so it's easy to keep the FIFO full but still sneak in non-motion queue commands. But that won't work for every project. The other way you can do it is to send two motion commends (one to execute, the other for the FIFO) and the poll the FIFO status. As soon as it goes empty, send one more motion command. This lets the PC software (rather than USB) do the flow control, which can have some real advantages because you're still free to send any other commands as often as you want. The downside is that you're then only one motion command from running dry, which can cause stuttering motion as the EBB has no motion commands to execute for small amounts of time. Your idea about having the EBB send a response packet to the PC when the FIFO status changes is a good one. Could you open a separate issue for that, capturing your intent? The other nice thing to have would be an optional command to expand the size of the FIFO (we have plenty of free RAM). *Brian

…

On Fri, Dec 2, 2016 at 7:43 AM, Poul-Henning Kamp ***@***.***> wrote: Sorry for not keeping up, this is just a "as time permits" sparetime project for me. I'll try to test the new firmware this weekend. With respect to point 3: Yes, I realize that this is a general purpose board, but a lot of people will encounter it first on the EggBot or AxiDraw, and therefore adding a small not "Don't use SM for the AxiDraw, use XM instead." would have saved me a couple of very confused minutes. About the node counter: I'm not sure I ever understood what the purpose was, I merely observed that it did not work the way the documentation said it would. About the FIFO in general: Is it the intent that the computer tries to just keep the FIFO slot filled, or is it considered OK to blast commands at the EBB and rely on USBs flow-control ? In the first case, it might be an idea if the EBB could send a token to the computer when the FIFO empties, so that the interaction could be: Computer EBB cmd1 -> (starts cmd1) cmd2 -> (goes into fifo) (wait for msg from EBB) (cmd1 completes, cmd2 taken from fifo) <- fifo empty cmd3 -> (goes into fifo) (wait for msg from EBB) (cmd2 completes, cmd3 taken from fifo) <- fifo empty cmd4 -> (wait for msg from EBB) (cmd3 completes, cmd4 taken from fifo) <- fifo empty (poll with QM until cmd4 motion stops) Alternatively one could do an optional flag on the motion commands that says "Send me a notice when this motion starts" — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbeCPeyz-R0BCz0phsOVXK7_6QHSDOEks5rECBogaJpZM4KyRNa> .

[oskay]

"Don't use SM for the AxiDraw, use XM instead."

I strongly disagree with that statement. The current AxiDraw driver uses the SM, not the XM, command. Telling people that only one of those commands can (or should) be used for it is a falsehood.

(Probably not on your radar, but the original AxiDraw had independent X and Y axes. While XM can be used for it, it's really much more straightforward to use the SM command for that first AxiDraw.)

If the SM and XM commands worked equally (they do not), then perhaps we could say that XM is recommended for use with the AxiDraw v2.0 and above. But at present, I wouldn't go even nearly as far as to say that XM is recommended, since we don't use it ourselves in most circumstances.

The current phrasing there is "This command is designed to allow cleaner operation of machines like the H-Bot and CoreXY systems." This should be updated, since the "H-Bot" link there is broken. (It was a machine with the same geometry as the AxiDraw.) Perhaps we could update it to something like:

"This command is designed to allow cleaner operation of machines with mixed-axis geometry, including CoreXY, H-Bot gantry machines, and current AxiDraw models."

[EmbeddedMan]

Ooo! I didn't realize that AxiDraw was using SM. I will update the doc immediately to your suggested wording. *Brian

…

On Fri, Dec 2, 2016 at 12:15 PM, Windell Oskay ***@***.***> wrote: "Don't use SM for the AxiDraw, use XM instead." I strongly disagree with that statement. The current AxiDraw driver uses the SM, not the XM, command. Telling people that only one of those commands can (or should) be used for it is a falsehood. (Probably not on your radar, but the original AxiDraw had independent X and Y axes. While XM can be used for it, it's really much more straightforward to use the SM command for that first AxiDraw.) If the SM and XM commands worked equally (they *do not*), then perhaps we could say that XM is *recommended* for use with the AxiDraw v2.0 and above. But at present, I wouldn't go even nearly as far as to say that XM is recommended, since we don't use it ourselves in most circumstances. The current phrasing there is "This command is designed to allow cleaner operation of machines like the H-Bot and CoreXY systems." This should be updated, since the "H-Bot" link there is broken. (It was a machine with the same geometry as the AxiDraw.) Perhaps we could update it to something like: "This command is designed to allow cleaner operation of machines with mixed-axis geometry, including CoreXY, H-Bot gantry machines, and current AxiDraw models." — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbeCLGEvYz6lnW0WeP2RlTFwf23FeSjks5rEGBCgaJpZM4KyRNa> .

[EmbeddedMan]

Windell - as a semi-related issue, do you have any reason to believe that XM is broken in any way or inconsistent with our documentation? On Fri, Dec 2, 2016 at 12:21 PM, Brian Schmalz <brian@schmalzhaus.com> wrote:

…

Ooo! I didn't realize that AxiDraw was using SM. I will update the doc immediately to your suggested wording. *Brian On Fri, Dec 2, 2016 at 12:15 PM, Windell Oskay ***@***.***> wrote: > "Don't use SM for the AxiDraw, use XM instead." > > I strongly disagree with that statement. The current AxiDraw driver uses > the SM, not the XM, command. Telling people that only one of those commands > can (or should) be used for it is a falsehood. > > (Probably not on your radar, but the original AxiDraw had independent X > and Y axes. While XM can be used for it, it's really much more > straightforward to use the SM command for that first AxiDraw.) > > If the SM and XM commands worked equally (they *do not*), then perhaps > we could say that XM is *recommended* for use with the AxiDraw v2.0 and > above. But at present, I wouldn't go even nearly as far as to say that XM > is recommended, since we don't use it ourselves in most circumstances. > > The current phrasing there is "This command is designed to allow cleaner > operation of machines like the H-Bot and CoreXY systems." This should be > updated, since the "H-Bot" link there is broken. (It was a machine with the > same geometry as the AxiDraw.) Perhaps we could update it to something like: > > "This command is designed to allow cleaner operation of machines with > mixed-axis geometry, including CoreXY, H-Bot gantry machines, and current > AxiDraw models." > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#63 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAbeCLGEvYz6lnW0WeP2RlTFwf23FeSjks5rEGBCgaJpZM4KyRNa> > . >

[oskay]

XM is not broken, it's just not optimal. It is a very useful shortcut for general purpose use.

Since the XM(A,B) command inputs are checked after doing the A+B, A-B math on the inputs, best practice is to calculate X = (A+B) and Y = (A-B) and to range-check them before sending the command. (Otherwise, the command could be rejected, causing loss of the job.) Once you've computed X and Y, and constrained the inputs within that context, one then has a choice:

• Re-compute the A and B values from the new X and Y values (which has code complexity and computational time costs), so that you can use the XM command, or
• Just send the SM command

There are really zero benefits to the former option.

[EmbeddedMan]

Ahh, yes. That makes total sense.

…

On Fri, Dec 2, 2016 at 12:41 PM, Windell Oskay ***@***.***> wrote: XM is not broken, it's just not optimal. It is a very useful shortcut for general purpose use. However, since it's inputs are checked after doing the A+B, A-B math on the inputs, best practice is to calculate X = (A+B) and Y = (A-B) and to range-check them before sending the command. (Otherwise, the command could be rejected, causing loss of the job.) Once you've computed X and Y, and constrained the inputs within that context, one then has a choice: - Re-compute the A and B values from the new X and Y values (which has code complexity and computational time costs), so that you can use the XM command, or - Just send the SM command There are really zero benefits to the former option. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#63 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAbeCIDaamJI3tkUx1h6od4JIVO1LZGcks5rEGZigaJpZM4KyRNa> .