Support 'Named EBBs' to allow plotting to many AxiDraws #39
Comments
|
Not sure that this is a necessary part of that process; each USB port connection already has a unique name. It would be neat if there were an ability to save a name string (e.g., in EEPROM). |
|
Agreed - I don't think this naming ability is required, but it would really make things easier for users. You could have 3 EggBots, and give them each nice names ("Yoke", "White", and "OverEasy") which would make selecting one to print to at plot time much easier. Since we don't have EEPROM on the EBB, we will simply dedicate a block of Flash for this functionality (as well as other things we might want to store there in the future). Microchip has a nice EEPROM emulation library we can use for this. I think the more difficult part is in the Inksacpe extension. The thing is, you could walk through the list of all available com ports (like we do now), but also ask each EBB what it's name is. Then let the user pick which one (if there is more than one) they want to plot to. This won't work if there is already some app that is in the middle of plotting to one of the EBBs, as you won't be able to open up a com port to it and ask it what it's name is. That's why having it's name appear in the Device Manager (which is just part of the USB information that the OS keeps cached on each device) means you could get it's name even if somebody else is printing to it. This will increase the complexity of the Inkscape plugin, at least at 'detect' time. But hopefully it's deemed worth while . . . |
|
My bigger concern is with total execution time if we're running multiple machines at once. There is computation time involved on the computer, and it tends to slow things down. |
|
Sure, that very well may be a problem. Someone who's going to be plotting
10 EBs at once should probably not use a slow machine then! But I think
many machines today would be fast enough for even just two simultaneous
plottings, which would make demoing multiple EBB based robots from one
computer possible.
…On Sat, Aug 12, 2017 at 2:17 PM, Windell Oskay ***@***.***> wrote:
My bigger concern is with total execution time if we're running multiple
machines at once. There is computation time involved on the computer, and
it tends to slow things down.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCLOOKSUy45BpkCEoJW87Ip39E0BEks5sXfpfgaJpZM4O1atK>
.
|
|
What would it take to get this up and running? (Assuming that we can manage it from the software side...) |
|
Probably not very hard I think. Let's talk about implementation : my first
thought is to create two new EBB commands, one would 'set' a name, and the
other would 'get' whatever name was previously set.
On the PC side, you'd have to figure out how to handle things when somebody
goes to plot - do they get a drop down list of all available EBBs to pick
from? I guess that would mean opening up each one in turn and querying each
one's name in turn to populate the list.
Or would you go simpler than that - when you plot, you can fill in an
optional 'name' field before plotting, and the plugin will walk through all
available COM ports looking for that name, then when found, start plotting.
The other thing to consider - I think we can append the 'set' name to the
USB identification string that the OS gets access to when the device is
first enumerated. You could then get a list of all attached EBBs (with
their names) from the OS without having to open all of their COM ports and
ask them each what their names are. However, if we were to add this feature
in, we'd have to re-enumerate (i.e. reboot the EBB) after any name change.
…On Fri, Jan 5, 2018 at 1:07 PM, Windell Oskay ***@***.***> wrote:
What would it take to get this up and running?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCMvVF864DJlM7q_AQdr-n4wn2DQBks5tHnMEgaJpZM4O1atK>
.
|
|
It won't be possible to list the attached devices within Inkscape; the extension format isn't that flexible. Yes, having an optional place to specify which EBB is plausible. (If none specified, use the first one found -- the default option.) Yes, listing the names with the id (maybe "EiBotBoard,Sally") would be helpful. Ideally, we could then search through the com ports without interrupting a plot already in progress on another. Separately: Some people would benefit from a plotting mode where multiple machines are controlled simultaneously, acting in unison. Something to ponder for the future. |
|
OK, very good. I'll work on adding the set and get name commands to the EBB
firmware.
As for simultaneous printing - wouldn't that be purely an Inkscape
extension thing? (i.e. open up many com ports, and send the same command to
each one)
…On Fri, Jan 5, 2018 at 1:47 PM, Windell Oskay ***@***.***> wrote:
It won't be possible to list the attached devices within Inkscape; the
extension format isn't that flexible.
Yes, having an optional place to specify *which* EBB is plausible. (If
none specified, use the first one found -- the default option.)
Yes, listing the names with the id (maybe "EiBotBoard,Sally") would be
helpful. Ideally, we could then search through the com ports *without*
interrupting a plot already in progress on another.
Separately: Some people would benefit from a plotting mode where multiple
machines are controlled simultaneously, acting in unison. Something to
ponder for the future.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCNZMHgKcq6KubSXgNua-Ie2QXrWRks5tHnxBgaJpZM4O1atK>
.
|
|
I could imagine spawning multiple processes that each plot a file, but changing things to have one process send the same command to each and every machine, then wait for responses from each and every machine sounds like a recipe for slow and painful disaster. |
|
I've actually done exactly that (8 com ports open in one process) in
node.js and it worked extremely well. Including waiting for replies from
each board, all running as far as possible. It was a 8 channel radio
protocol analyzer. You just have to play with it enough to get the software
architecture right.
…On Jan 5, 2018 2:33 PM, "Windell Oskay" ***@***.***> wrote:
I could imagine spawning multiple processes that each plot a file, but
changing things to have one process send the same command to each and every
machine, then wait for responses from each and every machine sounds like a
recipe for slow and painful disaster.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCPzFLagDlJ1ZZP1oo1q-Yh6NnSKQks5tHocsgaJpZM4O1atK>
.
|
|
It certainly does not handle the case if you want to pause one machine... |
|
Well, it _could_. If it's critical to keep them all exactly synchronized,
then everything must be done in lockstep. If you detect that the pause
button (any pause button) is pushed, you stop all of the outgoing streams.
Yes, you'll have to wait for each of the plotting EBBs to return with a
result for each command, but that's OK - you want everything to be
perfectly synchronized anyway, so you'll always be slaved to the slowest
unit.
Of course, if you really wanted to be exact about it, you could simply turn
on the external driver outputs from ONE EBB, and run that into any number
of separate stepper drivers in parallel, each driving an AxiDraw. Each step
in all of the plotters would then be perfectly synchronized - and only one
pause button.
In any case, there are a lot of things to decide with this type of scheme,
and it would depend on exactly what the user expectations and requirements
are I guess.
…On Fri, Jan 5, 2018 at 2:46 PM, Windell Oskay ***@***.***> wrote:
It certainly does not handle the case if you want to pause *one*
machine...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCNCW4_chuBskPqy6pSDenCf9UKF_ks5tHoo5gaJpZM4O1atK>
.
|
|
OK, so I've got it working - saving and getting names from FLASH. Because
this part doesn't have a separate EEPROM, we have to use a page (1024)
bytes of Flash to store the name. In order to prevent a situation where
losing power during a flash erase/write cycle could brick the EBB, we
actually have to reserve two pages of Flash - one holds the 8 bytes of
config bit information (the last page from 0xFC00 to 0xFFFF), and then the
second to last one to hold our name (0xF800 to 0xFBFF). This isn't a
problem - we still have left over Flash even after this change but it's not
the most efficient thing in the world.
Now I need to get the name to appear as part of the USB string at this one
will be done.
…On Fri, Jan 5, 2018 at 3:41 PM, Brian Schmalz ***@***.***> wrote:
Well, it _could_. If it's critical to keep them all exactly synchronized,
then everything must be done in lockstep. If you detect that the pause
button (any pause button) is pushed, you stop all of the outgoing streams.
Yes, you'll have to wait for each of the plotting EBBs to return with a
result for each command, but that's OK - you want everything to be
perfectly synchronized anyway, so you'll always be slaved to the slowest
unit.
Of course, if you really wanted to be exact about it, you could simply
turn on the external driver outputs from ONE EBB, and run that into any
number of separate stepper drivers in parallel, each driving an AxiDraw.
Each step in all of the plotters would then be perfectly synchronized - and
only one pause button.
In any case, there are a lot of things to decide with this type of scheme,
and it would depend on exactly what the user expectations and requirements
are I guess.
On Fri, Jan 5, 2018 at 2:46 PM, Windell Oskay ***@***.***>
wrote:
> It certainly does not handle the case if you want to pause *one*
> machine...
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#39 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAbeCNCW4_chuBskPqy6pSDenCf9UKF_ks5tHoo5gaJpZM4O1atK>
> .
>
|
|
Windell, I just realized something that might be interesting to you - in
order to add the stored name to the Product String Descriptor that the USB
stack uses, I need to make some changes to the USB stack in order to allow
for RAM based string descriptors, rather than only ROM based ones as things
are set up now.
This means that we could also add a "USB Serial Number" to the EBB if we
wanted to, which would get stored in Flash just like our name.
This number will have the effect of causing the EBB to always have the same
COM port number no matter where you move it around on a given PC.
Normally, if you plug in a USB device that has no serial number, then
Windows will assign a COM port based on where that device is in the USB
'tree' for that computer. So if you unplug EBB "A" and plug in EBB "B" in
the same place, both will get the same COM port number.
But if those devices have serial numbers (and they're different), then
Windows will tie the COM port to the serial number. So if you plug in EBB
"A" (with a serial number) at a location and it is given COM21, then plug
it in somewhere else on that PC, it will still have COM21 no matter where
you plug it in. And if you plug in EBB "B" in that first location, Windows
will give it a new COM port number because it knows that it's a different
device (because it has a different serial number).
I'm not sure how Linux and MacOS do it.
You'd likely want to assign unique serial numbers to each EBB (or have
Seeed do it) via some new command.
Anyway, I'm not putting it in right now, but think about it if it's
something you would want added in the future.
This is probably a completely useless suggestion as the Inkscape plugin
already does a good job of finding EBBs without knowing their COM port
numbers.
…On Fri, Jan 5, 2018 at 6:04 PM, Brian Schmalz ***@***.***> wrote:
OK, so I've got it working - saving and getting names from FLASH. Because
this part doesn't have a separate EEPROM, we have to use a page (1024)
bytes of Flash to store the name. In order to prevent a situation where
losing power during a flash erase/write cycle could brick the EBB, we
actually have to reserve two pages of Flash - one holds the 8 bytes of
config bit information (the last page from 0xFC00 to 0xFFFF), and then the
second to last one to hold our name (0xF800 to 0xFBFF). This isn't a
problem - we still have left over Flash even after this change but it's not
the most efficient thing in the world.
Now I need to get the name to appear as part of the USB string at this one
will be done.
On Fri, Jan 5, 2018 at 3:41 PM, Brian Schmalz ***@***.***>
wrote:
> Well, it _could_. If it's critical to keep them all exactly synchronized,
> then everything must be done in lockstep. If you detect that the pause
> button (any pause button) is pushed, you stop all of the outgoing streams.
> Yes, you'll have to wait for each of the plotting EBBs to return with a
> result for each command, but that's OK - you want everything to be
> perfectly synchronized anyway, so you'll always be slaved to the slowest
> unit.
>
> Of course, if you really wanted to be exact about it, you could simply
> turn on the external driver outputs from ONE EBB, and run that into any
> number of separate stepper drivers in parallel, each driving an AxiDraw.
> Each step in all of the plotters would then be perfectly synchronized - and
> only one pause button.
>
> In any case, there are a lot of things to decide with this type of
> scheme, and it would depend on exactly what the user expectations and
> requirements are I guess.
>
> On Fri, Jan 5, 2018 at 2:46 PM, Windell Oskay ***@***.***>
> wrote:
>
>> It certainly does not handle the case if you want to pause *one*
>> machine...
>>
>> —
>> You are receiving this because you authored the thread.
>> Reply to this email directly, view it on GitHub
>> <#39 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AAbeCNCW4_chuBskPqy6pSDenCf9UKF_ks5tHoo5gaJpZM4O1atK>
>> .
>>
>
>
|
|
OK, the change is in and, from my limited testing so far, works. Three new commands : "NS" for Name Set, "NG" for Name Get, and "RB" for ReBoot. So far it's sitting on the "EBB_Naming" branch, so please check that branch out and update your firmware to test it out on your own. Before we merge this change in and make this version final, it really should be tested out to make sure that it doesn't bork anything up, and to make sure that it's actually usable by the Inkscape extension. (I'm not sure how the Inkscape extension can query the Device Names. Hopefully there is an easy way.) Under Windows, you can use the program USBDeview (http://www.nirsoft.net/utils/usb_devices_view.html) if you want to see the Device Name of every attached USB device. This will show you that the EBB's name gets appended to the normal device name. Note that the name shown in the Device Manger (which is technically called the "Display Name" of the device in Windows) is hard-coded in the .inf file which is installed as part of the EBB drivers. I don't know how to change that string from the EBB firmware, or if there even is a way. So that string in the Device Manager will still say "USB Serial (UBW-based) communications port (COMxx)". It's only the "Device Name" which we have control over from the firmware. The documentation has been updated with the three new commands, as have the release notes. I'll continue to do testing here on different versions of Windows. If you could test on your systems and report back once you're able to get the extension to use this new command, then we can merge this change in. |
|
OK, hold on for a bit before testing - a bug has been found and version 2.5.4 will be re-released shortly on the branch. The bug is that a blank line is NOT printed if the name field has never been set before (the docs say that this will happen). |
|
Awesome. For consistency, I would prefer that the query command starts with a (or at least contains) a Q. |
|
Also, here is the general syntax that we use to check for the EBB name: https://github.com/evil-mad/plotink/blob/master/libraries/ebb_serial.py#L42 |
|
Oh, that's awesome! I think it will be very easy for you to modify that code to look at the rest of the string (after the "EiBotBoard") to see if there is a name attached, and then do a match based on that with which EBB the user wants to plot to. Splendid. I will rename the commands and get updated docs in shortly. |
|
OK, we should be all good now. v2.5.4 is updated to use the new command names, and the docs have been updated as well. All still on the EBB_Naming branch. Give it a go, and let me know what you think. |
|
Is there a compelling reason to have a separate RB command versus reset? |
|
Yes, I think so.
The "R" command does not actually reset the processor. It undoes any
'unique' setup you may have done to the I/O directions or states, and
returns everything to how it should be (what pins are inputs, what are
outputs, what pin has RC servo output on it, etc.)
The "RB" command is for completely dropping off the USB, then rebooting the
processor as if power had just been applied.
I can see use cases (maybe not for EB/WCB/AD, but for others) where the two
different types of resetting could be useful.
*Brian
…On Sun, Jan 7, 2018 at 9:38 PM, Windell Oskay ***@***.***> wrote:
Is there a compelling reason to have a separate RB command versus reset?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCMiUCLvL4G0EDeWRUzYjsM2YKFMjks5tIY2hgaJpZM4O1atK>
.
|
|
Perhaps it would be good to clarify the difference between the two in the documentation. |
|
OK, sure. I've just make a change. See if you like it.
…On Sun, Jan 7, 2018 at 10:01 PM, Windell Oskay ***@***.***> wrote:
Perhaps it would be good to clarify the difference between the two in the
documentation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#39 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAbeCBHfbHExfuloFxFcUakFFaHG1dROks5tIZM3gaJpZM4O1atK>
.
|
|
Yes, that's much better. |
|
Working and committed.
|
Not sure how or even if this is possible from Inkscape. But if the EBB gets a new 'name' command (issue 83 in EggBot) then it might be possible to have multiple instances of Inkscape open, and somehow choose one of the available AxiDraws by EBB name. Also a way to set the name of a given EBB.
The text was updated successfully, but these errors were encountered: