Any working GUI / graphical user-interface / g-code-sender for g2core?

[rkoe]

Is there any working GUI / graphical user-iterface / g-code-sender for g2core on Arduino DUE? I've tested several, but all failed:

• cnc.js: Looks good, but is very slow; when gcode runs, the browser-interface uses 100% cpu, but the display is rarely updated (e.g. the shown position is only updated every 10-30s or so, and usually much behind the machine), and feedholds are delayed up to e.g. 7 seconds (!). So, I can load and start some gcode, but when the gcode runs, no sensible data is displayed and I can't operate the machine.

• Goko: Needs Java 8 to offer g2core-support (otherwise it silently doesn't offer g2core-support), the GCode-viewer and -editor are completely broken (=empty), and the whole interface often hangs during gcode execution. Feedhold/resume does not work reliably, the "Pause"-button is usually disabled, and it sometimes also crashes g2core.

• UniversalGcodeSender-v2.0.0 / UniversalGcodeSender-v1.0.9 / ugsplatform-2.0.0: Do not work with g2core.

• chilipeppr: Only works with internet-connection (wtf?). Does not support M0, feedhold does not work on arcs, crashes g2core after feedhold-on-arc.

The best way currently is using minicom or python-serial and send the commands manually. :(

[justinclift]

Yeah, I hit the same problems. Actually wrote my own super basic (non-graphical) g-code sender, which literally just dumps a file straight to the g2core tty/com port. With very basic setup / initialisation at the start:

    https://github.com/justinclift/g2sender

Doesn't yet accept any keyboard input. So, no feed hold, no pause, no resume. (!)

It's written in Go, which means it's pretty easy to understand compared to (say) C++ or more complex languages. It's also easily cross platform (tested on CentOS 7.x, and Win 7).

Not sure if it'll be suitable for you though. I just needed something for quick testing, and this does the job for now. I do plan to make it a bit nicer to use (prob use a state machine and also do some ncurses stuff), but not really wanting to spend huge time on it. :smile:

[justinclift]

Oh, have you taken a look at this yet?

    https://github.com/synthetos/node-g2core-api

That might be useful. From (dodgy) memory, when I tried it out it only "kind of" worked, thus my writing the super basic g2sender thing. But you may have more luck. :smile:

[ril3y]

Shopbot actually uses this:

http://gofabmo.org/

Its supposed to be geared towards smart machines so you can adjust it to fit your needs.

Riley

[justinclift]

Interesting. From a cursory look it seems a bit complicted to setup. But, haven't gone through the process to actually try it out yet. Might turn out to be simple and work perfectly. :smile:

[rkoe]

I've now written a small text-mode-tool (incl. feedhold and mini-terminal) in Python. It works, and I've found some unexpected behaviour of g2core (see other issues). (I'll probably extend my tool by ncurses and/or GTK+ in the future.)

node-g2core-api does not really help, since afaik it's only a "enhanced terminal", but not a g-code-sender.

gofabmo looks interesting, but seems to be tailored to their hardware. I got it running, but then it told me to "press the green button for some seconds"...

[giseburt]

node-g2core-api has a binary utility 'g2' in it if installed globally. It follows the line mode (and is what we use to formulate and test line-mode).

It needs some updating, but works well in node 6. (NPM throws some interesting but ignorable warnings when installing.)

It works to send files as well as act as in interactive terminal. I use it for both extensively.

-Rob

On Apr 26, 2018, at 4:53 PM, Roland Koebler notifications@github.com wrote:

I've now written a small text-mode-tool (incl. feedhold and mini-terminal) in Python. It works, and I've found some unexpected behaviour of g2core (see other issues). (I'll probably extend my tool by ncurses and/or GTK+ in the future.)

node-g2core-api does not really help, since afaik it's only a "enhanced terminal", but not a g-code-sender.

gofabmo looks interesting, but seems to be tailored to their hardware. I got it running, but then it told me to "press the green button for some seconds"...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/342#issuecomment-384800652, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXj0dHxTd9widAw3-6U7DqsFfzbA2PEks5tskG_gaJpZM4TkRgb.

[justinclift]

@rkoe

I've now written a small text-mode-tool (incl. feedhold and mini-terminal) in Python. It works, and I've found some unexpected behaviour of g2core (see other issues). (I'll probably extend my tool by ncurses and/or GTK+ in the future

Cool. Did you chuck it up on GitHub? Yep, that's me wanting to be lazy as having to make my own gcode sender isn't really a personal goal. :grinning:

So, if I can just use yours and it works "well enough" without having to continue mine, I'd consider that a (personal) win. :wink:

@giseburt

node-g2core-api has a binary utility 'g2' in it if installed globally.

Pretty sure I tried that early on, but hit issues. I'll give it another shot in the near future and see if it was just my newbie-ness at the time or if it was something else. :smile:

There was one non-critical warning message, but that's not a biggie.

[rkoe]

Yes, I will publish my g-code-sender. It already works pretty well. :smile:

It does not yet have a nice graphical user-interface; it's just some kind of enhanced serial console which runs in a Linux-terminal. But you can run g-code-programs, use feedhold/resume/flush and directly communicate with g2core for everything else. It also periodically displays the current machine-state, the currently executed g-code-line and the current coordinates/feed/velocity, and it stops at M0 and shows (msg) to the user. :smiley: I'm currently enhancing it a bit, and then you can try it out.

[yck011522]

Thanks rkoe for testing so many software. I would love to see some GUI solution for a Windows machine that doesn't involve some tweaking to get it to work.

[justinclift]

I'm currently enhancing it a bit, and then you can try it out.

Awesome. :smile:

Would it be feasible to have some kind of "initialisation code" that gets sent to the g2core board automatically when the connection is made?

eg sending the various tuning parameters, so people don't have to compile their own firmware

That would nicely complement #340 (which I'll probably manually upload initial .elf/bin files for today).

This would let people download a working .elf/.bin file from the Releases page, flash their firmware with it, and also have a working G-code sender program which they can store their settings in. No need to compile anything.

[rkoe]

Would it be feasible to have some kind of "initialisation code" that gets sent to the g2core board automatically when the connection is made?

Yes, of course. I've planned a machine-config-file.

Note that some GUIs already do this: In cnc.js you can define a macro for this, and I think goko (or UGS?) has a config-dialog.

[giseburt]

In the g2 utility that’s in node-g2core-api you can use the -i option to send a JSON file of configs to the board on connection. On Sat, Apr 28, 2018 at 1:19 PM Roland Koebler notifications@github.com wrote:

Would it be feasible to have some kind of "initialisation code" that gets sent to the g2core board automatically when the connection is made?

Yes, of course. I've planned a machine-config-file.

Note that some GUIs already do this: In cnc.js you can define a macro for this, and I think goko (or UGS?) has a config-dialog.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/synthetos/g2/issues/342#issuecomment-385195948, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXj0X-wzkLSFqLxkUQwlr9eQqoaJxx-ks5ttLK9gaJpZM4TkRgb .

[justinclift]

Awesome. :smile:

[msepulve]

@rkoe said: “gofabmo looks interesting, but seems to be tailored to their hardware. I got it running, but then it told me to "press the green button for some seconds"...

As a Handibot/FabMo user I can attest that FabMo is indeed a great GUI. Although it was developed for Shopbot Tools hardware, it’s highly customizable. The main development has been on Edison, but it can run on other hardware/OS. As a matter of fact, I have it running on a Raspberry Pi. Now to your problem of “press the green button”, please be advised that this can also be modified in the following way: In “Configuration”, look for “Menu”, then “Machine” and there in the third row “Authorization Button”, select “No authorization” then you are all set. At least this is how I set it in the version from 2017 I have. In newer versions may be slightly different. I have been trying to use it with DUE/gShield Harware, but as the mapping of the FabMo HW is very different (indeed only two pins are 100% coincident) my testing has been very limited but it basically works. I would be very thankful if some one can give me guidance to modify the pin mapping of the sbv-300 software to run the DUE/gShield with FabMo. Thanks!

[justinclift]

Ahhh. Is there something I can look at to see what the connections for the FabMo needs to be?

With that info, I can probably help you out with this.

For example, looking at the Ardunio Due pinout (when compiled with the gShield settings), there are some initial basic bits:

Motor	Step or Direction	Due pin
1	Step	2
1	Direction	5
2	Step	3
2	Direction	6
3	Step	4
3	Direction	7
4	Step	31
4	Direction	32
5	Step	37
5	Direction	38
6	Step	42
6	Direction	43

Note - I've only gotten around to hooking up 4 motors so far, so I haven't yet tried out bits for motors 5 and 6.

For the limit switches:

Axis	Min or Max	Due pin
X	Min	14
X	Max	15
Y	Min	16
Y	Max	17
Z	Min	18
Z	Max	19

There are pins for other things (eg microstepping, motor enable, A/B/C Min&Max's, coolant on). I haven't personally needed those (yet), but you should be able to figure them out from the diagram.

Does that help? :smile:

[justinclift]

Thinking about it more... the above might only be useful if you're wanting to wire things into the Due pin headers yourself. If you're wanting to adjust the g2core pin configuration to match the hardware you have, that's do-able too. It just means you'll need to change the pinout mapping before compiling.

Probably the simplest way (from memory) is to change them directly in your copy of the file here:

https://github.com/synthetos/g2/blob/edge/g2core/board/ArduinoDue/gShield-pinout.h

... without changing the filename or anything, so that when you compile for the gShield it'll pick up your changed settings. Once you've experimented with that and gotten the hang of things, you'll be in a good position to read the various wiki pages explaining how to create your own proper board definitions. :smile:

eg:

• https://github.com/synthetos/g2/wiki/Adding-and-Revising-Boards

[msepulve]

@justinclift thank you very much for your comments and recommendations. When starting FabMo, it automatically uploads to the Due the firmware (g2.bin which is a g2core bin compiled with the sbv-300 definitions) and doesn’t work with gShield bins. Conversly, the g2.bin for FabMo (sbv300) don’t work in Chilipeppr. I also think that the different FabMo GUI versions are somehow “aligned” with the versions of the G2 firmware. Accordingly, any remapping must be made in the sbv300 board files. My first question is whether will be enough to modify the https://github.com/synthetos/g2/blob/master/g2core/board/sbv300/sbv300-pinout.h file or it’s also required to modify the https://github.com/synthetos/g2/blob/master/g2core/board/sbv300/motate_pin_assignments.h file or other files in the sbv300 folder. As an examples of the modification to be made for the motors, the following table shows how the sbv300 pins are now and to what ports the should be mapped so to address the correct pins in the Due/gShield hardware.

                Sbv-300                    DUE/gShield  
             PORT     DUE Pin             PORT        DUE Pin

m1step C28 3 B25 2 m2step C25 5 C28 3 m3step C26 4 C26 4

m1dir B23 x C25 5 m2dir B24 x C24 6 m3dir B14. 53 C23 7

As the table shows, in the actual sbv300-pinout.h the ports for the m1dir and m2dir don’t even show in the Due. So except for the m3step, all the other definitions must be changed to fit the Due/gShield pinout. If you point me to the files required to be changed, I will modify them and compile the firmware to make the testing and report the results here. Having solved that, I can proceed to modify the inputs and outputs which a are also mapped in a differen Again, in think that the FabMo GUI is an excellent alternative to interact with your CNC.

[msepulve]

Sorry for the miss alignment on the table. I wasn’t able to correct them.

[justinclift]

Sorry for the miss alignment on the table. I wasn’t able to correct them.

No worries. GitHub's version of markdown is useful for simple tables, but can't really do much more than that. Not your fault.

With the pin assignment bits, I'll try to grok this tomorrow. I'm brain fried atm after getting some other things taken care of, so not capable of absorbing new info atm. :roll_eyes:

[justinclift]

Looking at the wiki page which covers motate pins and how they map to a physical board, it sounds like you'd just need to update the pin definitions in sbv300-pinout.h, and don't need to touch the motate_pin_assignments.h file. The wording in that wiki page could be clearer though.

Looking at your tables, I think you have the right idea already.

So, it'd be something along the lines of this:

Item	Change to
Motor 1 step	B 25 (should be physical pin 2 on the Due)
Motor 1 dir	C 25 (should be physical pin 5 on the Due)
Motor 2 step	C 28 (should be physical pin 3 on the Due)
Motor 2 dir	C 24 (should be physical pin 6 on the Due)
Motor 3 step	C 26 (should be physical pin 4 on the Due)
Motor 3 dir	C 23 (should be physical pin 7 on the Due)

Same as your table. That's my initial guess anyway.

Does that help? :smile:

[justinclift]

Hmmm, the mention of FabMo engine being tied to specific g2core revisions could make things tricky. That might need some investigation to find out what the expected version is, and wind the repo source back to that specific one. Shouldn't be too hard to find out... maybe just ask @ryansturmer or create an issue on the FabMo Engine page to ask there? :smile:

[justinclift]

@yck011522 If you're still looking for a solution, I've been using the downloadable windows app version of CNCjs recently, with the master branch of g2core, and it seems to work ok so far.

That was on a Windows 7 64-bit computer though. Not sure which version of Windows you're using. :wink:

[yck011522]

Thank you very much Justin. I'll give it a try in my next project. -V

[justinclift]

You're welcome. :smile:

[msepulve]

@justinclift Thanks a lot Justin. I will try it tonight and let you know the result tomorrow around 15:00 GMT

[justinclift]

Awesome. Hopefully we're on the right track. :smile:

[msepulve]

@justinclift Good news! I compiled a first version changing only the configuration for the dir and step in the sbv300_pinout.h and I got output (connecting a Led) in the three stepper dir pins and also (weak) signals in the step output for the three motors. I compiled using the Master version available here in this site, with CONFIG=sbv300 SETTINGS_FILE="settings_shopbot_sbv300.h". Then renamed the file g2.bin and transferred to the Folder /fabmo/engine/firmware (before I had taken out the original g2.bin file) in the Raspberry Pi running FabMo. Then restarted FabMo and as it take cares of loading the firmware to the DUE, it was very easy. You may need to start, then stop and restart the FabMo to make sure the new version is loaded. Then I went to change also the input and output configurations and again it was successfull; at least I get signal in output 1 which control the spindle (or router in the FabMo). I have not verified yet either the other outputs, nor the input. So, if you need a GUI for CNC Machine, give FabMo a try. Thanks for your leads and encouragement.

[justinclift]

Muaaa Haaaa Haaaa! That's really excellent. Cool! :smile:

[justinclift]

@rkoe As data point stuff, with CNCjs I've not seen the slowness in operation so far personally. Only been using it for a few weeks on and off though, so I'm not yet an in-depth user.

My usage of it has been on two systems so far:

• A CentOS 7 x64 desktop. It has an older cpu (Core i5 750), 8GB ram, and a GTX 970 graphics card.
• A Win 7 x64 desktop. It has a pretty ancient cpu (Intel QX9650), 8GB ram, and a GTX 285 graphics card.

On the windows desktop I was using the Win7 downloadable app from the CNCjs release page. On the CentOS desktop I think it was installed via npm. (not remembering off hand)

[msepulve]

@justinclift I apologize for the early claim to sucess, with the compiled versions of g2core for the sbv300 and use with FabMo. I later realized that those firmwares were never loaded to the Due by FabMo. What I had loaded instead was TinyG2-gShield-087edge.bin that I had loaded with Chilipeppr connected to the native port of the Due. The good news is that version works with FabMo and has output for 3 stepper motors and output signal for the spinner. What is puzzling me now is the behavior of the Arduino Due in regards with g2 and FabMo. Following is a description of what I’m getting: 1) initially in the RPi, the command ls /dev/tty gets me /dev/ACM0 and /dev/AMA0 2) when I load the TinyG2-gShield-087edge.bin (from Chilipeppr), The same command list ACM0, ACM1 and AM0. I also get a yellow led blinking close to the native USB port. 3) If I run FabMo with the Due connected via the native port, FabMo will generate some error messages but will open port 80 and start the server which can be accessed with a browser. 4) if I connect to the FabMo server it works as explained. 5) please be advised that when the Due has the TinyG2 loaded, FabMo even doesn’t need to have a firmware (g2.bin) in the /fabmo/engine/firmware/ folder. So far so good, but the problems start when I load a g2core.bin firmware to the Due: I) only /dev/ttyACM0 and /dev/AMA0 are present (/dev/ttyACM1 disappears) and the LED stops blinking. II) if I try to run FabMo, I get an obvious error message “error: ERROR OPENING GCODE PORT Error: Cannot open /dev/ttyACM1 [g2]” at the very start and “UNCAUGHT EXCEPTION Error: G2 is not responding And then, “ at Watchdog.watchdog_exit [as _onTimeout] (/fabmo/engine/util.js:372:15) at Timer.listOnTimeout (timers.js:119:15)“ at the end. Of course no web server is opened. Accordingly FabMo needs both /dev/ACM0 and /dev/ACM1 to work but the latest is not available when I put a firmware compiled by me for the sbv300, or even the original FabMo g2.bin that I saved. So I guess my main question is: what does the TinyG2. bin version has that leaves both ACM0 and ACM1 open, while after loading the g2core versions for the sbv300 only ACM0 and AM0 are available? Secondly: how can I manually “unblock”or bring back the /dev/ACM1 needed by FabMo?

I have done many trials and I found the behavior of the Due somewhat random. I’m sure that I was able to load a firmware with FabMo sometime but I have been uncapable of reproduce it. Because of the above problem I have not been able to have a consistent method to load a customized firmware that will work with FabMo with Due/gShield. Hope someone can give me some pointers. thanks in advance!

[msepulve]

I forgot another importan issue. If I erase all the content of the DUE, to start from a “clean” state, I don’t get the required /dev/ttyACM1; only ACM0 and AMA0 are available. Then when starting FabMo I get: error: ERROR OPENING GCODE PORT Error: Cannot open /dev/ttyACM1 [g2] warn: Setting the disconnected state [machine] info: Got a machine state change: dead [machine] error: G2 is dead! [machine] error: !!!!!!!!!!!!!!!!!!!!!!!! [engine] error: Could not connect to G2. [engine] error: (Error: No connection to G2) [engine] error: !!!!!!!!!!!!!!!!!!!!!!!! [engine] info: Launching detection daemon... [engine] info: Loading the machine configuration... [engine] And finally UNCAUGHT EXCEPTION Error: G2 is not responding at Watchdog.watchdog_exit [as _onTimeout] (/fabmo/engine/util.js:372:15) at Timer.listOnTimeout (timers.js:119:15)

[giseburt]

When you erase the Due it starts booting from the loader in ROM, which will not respond with anything resembling g2core protocol, and will always only expose a single port.

[msepulve]

Ok thanks! So how can I get two ports exposed? Without two ports available in the native USB, FabMo can’t load it’s own firmware and also what I experienced is that loading TinyG2, allows working with FabMo but replacing the firmware is not allowed. So I’m blocked. I assert that I was able to load the FabMo firmware at least once (when I discovered that I had signal in only one step pin and one address pin in the Due), exactly as the sbv300_pinout.h shows) but have been unable to reproduce it again.

[justinclift]

The "two ports exposed" thing sounds familar:

• https://github.com/synthetos/g2/blob/d03a10e8b8ed6698aa2ff4baae45a4cc96b6f215/g2core/settings/settings_shopbot_sbv300.h#L64

Note that I haven't yet read back this thread, and probably won't have time to for a few days as I'm urgently focused on solving a problem for a different project (different headspace completely).

[justinclift]

Ahhh, found what I think is the matching info text for that in the wiki too (last two paragraphs):

These are the 2 endpoints for the dual endpoint USB connection. You can connect to either and it will work. For most purposes that's all you need.

If you want to run dual port mode, the first port opened will become a control and data port. If you open the second port it will become a data port, and the first will become control-only. Send Gcode to the data port, and everything else to the control port. All responses, status reports and exception reports will be returned to the control port - no text will be sent to the data port. This way you can queue a lengthy gcode file to the data port, while still having access to controls.

[ril3y]

FYI that is a compile time option so you would need to build 2 port support vs being a real time configurable option.

[msepulve]

thanks @justinclift and @ril3y . I followed your lead and found what you mention is in the file: g2/g2core/settings/settings_shopbot_sbv300.h and the actual instruction in the Master Version is:

define USB_SERIAL_PORTS_EXPOSED 1 // Valid options are 1 or 2, only!

for gShield I would guess the file used is settings_default.h and has the same instruction:

define USB_SERIAL_PORTS_EXPOSED 1

Does any one know if the Tiny G2 version 0.98 firmware build 87.01, was compiled with the above option set to 2 ? As I have experienced, that version exposes both a /dev/ACM0 and a /dev/ACM1 as observed by the comand ls /dev/ttyA*, as shown by the Arduino IDE, as output of serial-port-json-server and in Chilippeppr where in the Port List shows TinyG G2 /ttyACM0 & ACM1) which is coincident with the first image shown in the image at: https://github.com/chilipeppr/serial-port-json-server

The version https://github.com/synthetos/g2/releases/download/101.02/g2core-gShield-101.02.bin released recently only exposes one port /dev/ACM0 so I would say was it was complied with a setting of 1 as shown in the settings_default commented above. Am I correct? Thanks in advance for your comments:

[justinclift]

Yep that 101.02 version of g2core-gShield was definitely compiled with the setting of 1. Literally from this line:

https://github.com/synthetos/g2/blob/51f93aaa41e03b39d204067e4de1ed59c4529020/g2core/settings/settings_default.h#L147

Saying that because - for now - we don't have a specific settings file for the gShield, instead leaving it to use the defaults (in settings_default.h) as you guessed. I'm not sure about the 0.98 firmware though. That was way before my time (I'm new here). :smile:

[justinclift]

Thinking about it more... there's a decent chance the settings used for the ShopBot builds will be in a GitHub repo forked from this one. So, scanning quickly through the fork list here might be useful:

https://github.com/synthetos/g2/network/members

There are 3 forks for FabMo bits there, so I'd probably poke around in those and see if anything in there looks useful. :smile:

• https://github.com/FabMo/FabMo-G2-Core
• https://github.com/jbkarle/FabMo-G2-Core
• https://github.com/Sean3Don/FabMo-G2-Core

[justinclift]

@msepulve How feasible would it be to ask the ShotBot people if they have their config handy? Just thinking this might all be solvable with a simple email. :smile:

[msepulve]

@justinclift Indeed that's a good advise and I will certainly do that when I'm able to trace the problem to FabMo and not blocked by an issue that I'm not able to understand and solve in the compliation of G2. I think that if I'm able to compile a working gShield g2core.bin that works with the FabMoGui I will be able to address the right questions to them. Thanks! Can @giseburt comment how the TinyG2 G2 version 0.87 was compiled ?

[giseburt]

Version 0.87? I’m not sure what that would be. Do you perhaps mean 87.x?

FabMo current will work with edge, and AFAIK is tested against it.

FabMo stores it’s setting in a file. For example: https://github.com/FabMo/FabMo-Engine/blob/master/profiles/default/config/g2.json That is sent upon connection. You would need to switch profiles for your machine. Most likely your compiling in your settings and won’t need that file to contain anything but {}.

[giseburt]

I can’t find the docs for FabMo profiles (such as how to install them) but each machine has a different one. Here’s a handibot one: https://github.com/FabMo/fabmo-profile-handibot-2

[msepulve]

@giseburt Thanks for you comments. Here the results of querying the Due loaded with the gShield Tiny G2 version: $$ [fb] firmware build 87.01 [fv] firmware version 0.98 This version presents two serial ports ACM0 and ACM1 and work with my FabMo GUI installed in a Raspberry Pi. The more recent version g2core-gShield-101.02.bin only presents one port, ACM0 and has not worked with my FabMo installation. Now reviewing the files in the links you sent me, in the engine.json it’s clear that they use two ports: "control_port_linux": "/dev/ttyACM0", "data_port_linux": "/dev/ttyACM1", But in g2 , settings_shopbot_sbv300.h the instruction is: #define USB_SERIAL_PORTS_EXPOSED 1, Are these things related? Do you need to have two serial ports exposed to use control port and data port or it doesn’t matter? What are the benefits of using 2 instead of 1 in the above definition?

[justinclift]

Hmmm, is it feasible to try editing the engine.json file it's using?

If so, I'd (after making a backup) point both control_port_linux and data_port_linux to the same single port (eg /dev/ttyACM0) and try it out with the newer g2core build. Mainly to experiment and see if it works. It shouldn't hurt to try after all. :smile:

[msepulve]

@justinclift thanks for your recommendation, but at this point I think the problem is more related to the ideosincrtic behavior of the Due than anything else, as more often than not, the serial ports appear closed or non-existent for FabMo. What I have experienced is that when this firmware (http://storage.googleapis.com/chilipeppr-bucket/TinyG2-gShield-087edge.bin)is loaded to the Due, via Chilipeppr. It exposes ACM0 and ACM1 and it works with FabMo even when some errors messages are generated at start up.

Other firmwares (now even the original g2.bin) loaded to the Arduino with bossac, will expose only ACM0 and FabMo will generate messages like the following: info: Opening control port /dev/ttyACM0 [g2] info: Dual USB since control port and gcode port are different. (/dev/ttyACM0,/dev/ttyACM1) [g2] error: ERROR OPENING CONTROL PORT Error: Cannot open /dev/ttyACM0 [g2] warn: Setting the disconnected state [machine] info: Got a machine state change: dead [machine] error: G2 is dead! [machine] error: !!!!!!!!!!!!!!!!!!!!!!!! [engine] error: Could not connect to G2. [engine] error: (Error: No connection to G2) [engine] error: !!!!!!!!!!!!!!!!!!!!!!!! [engine] And at the end: warn: No callback passed to setMany [config] UNCAUGHT EXCEPTION Error: G2 is not responding at Watchdog.watchdog_exit [as _onTimeout] (/fabmo/engine/util.js:372:15) at Timer.listOnTimeout (timers.js:119:15)

Add to this that the same messages are generated by FabMo when Due is not connected at all. So, in my assessment, something/someone blocked the USB and or /dev/ACM0 so it doesn’t allow FabMo to read/write to that port. I also noticed that in this state, with the Due connected to Chilipeppr (via serial-port-json-server) I’m not able to upload firmware with Chilipeppr’s Arduino/Atmel programmer. Do you or someone else know if there exist a way to “unlock” the port without erasing the Due flash?

[ril3y]

I just emailed @ryansturmer to see if he could chime in here. He has developed much of fabmo. However he does not work for us :) So any help he can provide would be greatly appreciated.

[justinclift]

Good thinking @ril3y. :smile:

[msepulve]

Thanks @ril3y

[shczm]

@rkoe When will you put your Gcode sender on GitHub? I can not wait for trying it! :)