Pronterface/pronsole can't connect to Arduino-Due

[ebo]

I am experimenting with ruing Printrun on the new Repetier-Firmware Arduino-Due support. No matter what I do it will not connect, and when I crawl around in the code I see that _listen_until_online() in printcore.py:_listen() never returns even if I comment out the empty_lines == 15, and other hacks suggested in issue #401. As a note, I first started using printrun-20140126, and continued downgrading to printrun-20130711, and then tried running printrun's tip. No version is connecting.

As a side note, when it is trying to connect via _listen_until_online() in printcore.py:_listen(), if I hit the reset button it kills one of the threads -- which I am sure is NOT the desired failure mode.

Any suggestions appreciated.

[iXce]

Hmm, can you enable "Debug G-Code" option using latest master (option was broken before) and report everything that appears in the log panel ?

[ebo]

On Feb 15 2014 3:48 AM, Guillaume Seguin wrote:

Hmm, can you enable "Debug G-Code" option using latest master (option was broken before) and report everything that appears in the log panel ?

Thanks for the quick followup Guillaume!

Starting printrun with the command:

pronterface.py -a /tmp/TestModel.gcode

Just so that it has some file loaded, I get:

Connecting... Loaded /tmp/TestModel.gcode, 430 lines 27.2576001883 mm of filament used in this print The print goes:

• from 88.65 mm to 111.34 mm in X and is 22.69 mm wide
• from 90.05 mm to 109.94 mm in Y and is 19.89 mm deep
• from 0.00 mm to 2.10 mm in Z and is 2.10 mm high Estimated duration: 0:00:55 [INFO] Initialized 3D visualization in 0.00 seconds [INFO] Vertex count: 738 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 ...

and it never connects. I will dig up my extra Mega2560 and see if I get the same behaviour as the Due. That might take a little while though...

EBo --

[iXce]

Hmmm weird. Is the baudrate correct ? It seems there's no communication at all from the board Le 15 févr. 2014 16:15, "John (EBo) David" notifications@github.com a écrit :

On Feb 15 2014 3:48 AM, Guillaume Seguin wrote:

Hmm, can you enable "Debug G-Code" option using latest master (option was broken before) and report everything that appears in the log panel ?

Thanks for the quick followup Guillaume!

Starting printrun with the command:

pronterface.py -a /tmp/TestModel.gcode

Just so that it has some file loaded, I get:

Connecting... Loaded /tmp/TestModel.gcode, 430 lines 27.2576001883 mm of filament used in this print The print goes:

• from 88.65 mm to 111.34 mm in X and is 22.69 mm wide
• from 90.05 mm to 109.94 mm in Y and is 19.89 mm deep
• from 0.00 mm to 2.10 mm in Z and is 2.10 mm high Estimated duration: 0:00:55 [INFO] Initialized 3D visualization in 0.00 seconds [INFO] Vertex count: 738 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 [INFO] SENT: M105 ...

and it never connects. I will dig up my extra Mega2560 and see if I get the same behaviour as the Due. That might take a little while though...

EBo --

Reply to this email directly or view it on GitHubhttps://github.com/kliment/Printrun/issues/484#issuecomment-35158360 .

[iXce]

Any news on this issue ?

[ebo]

On Mar 20 2014 1:28 PM, Guillaume Seguin wrote:

Any news on this issue ?

---

Reply to this email directly or view it on GitHub: https://github.com/kliment/Printrun/issues/484#issuecomment-38210556

Not on my end. I had to give up and move on to other projects. Also, I have not played with it in weeks.

If you do find a solution, please let me know and I might pick it back up.

EBo --

[iXce]

Well, it's tough to find a solution without being able to debug the problem ^^ Let's keep the issue open and see if other people encounter it.

[ebo]

I should be able to break away a little time on the weekends to poke at this if others can give some guidance on how to instrument the code up to get adequate information to actually debug the problem ;-) That is what stumped me at the time... Otherwise I have decided to drop getting anything running on the Due and work with a controller that implemented a 9-DOF NURB on an FPGA, and implemented the nasty bits of the hard real-time kinematics on the FPGA so that LinuxCNC can control up to 9 axes at 5000 to 800kHz step rates via the USB... Interesting piece of kit ;-)

[iXce]

Well I think the first thing to check is that the baudrate you're using is the right one. If it is, are you able to connect to it using any other host program ?

[ebo]

The other interface programs I tried would not talk to the board at all (they did not recognize that any suitable board was connected and refused to get even that far). What I did instead was to play with the baud rate and see how it behaved. When the baud rate was set appropriately it behaved as described above. When it had a baud rate mismatch, it would die much earlier in the process (not recognizing the board). I put in a bunch of print statements and watched how it behaved. If you have time I can dig this all out and start playing with it a little over the weekend.

[iXce]

Okai, interesting. Sure, would be great ! Maybe the issue is that the repetier firmware is using a binary protocol which we don't handle ? Is there a way to configure it to use standard GCodes ?

[ebo]

Which, the FPGA-NURBS or repetier? I think they answer is yes on both counts. A NURB can exactly represent a conic section (ie circle or Bezier spline), and lines in a closed form representation. From here it is trivial to implement most g-codes. In fact, the FPGA-NURBS has been interfaced to LinuxCNC to use standard g and m codes, and take Bezier splines. They gave an example where they fed the controller the Bezier splines from True Type fonts, and traced Japanese Kanji with a pen adapted machine. They might have also cut it with one of their plasma cutters. I am not sure...

So, what would you like set up to test? If you give me an outline I will try to either do it, ot to give you an idea when I can take the time to poke at it -- I do not have the FPGA-NURBS controller set up at the moment, but just mounted the boards, motors, power supplies, and a single motor on din rails in a test-benching box...

[ebo]

Sorry, I mentioned the FPGA-NURBS controller but not repetier. I will look into that and how deeply any changes need to go to set it up to use standard g-codes.

[iXce]

Well, I meant the firmware which is currently running on your Due to which Printrun is fairly to talk ^^ If nothing is happening, it might just be that the firmware is expecting something which is not G-Code. So I am suggesting to check whether you can disable the binary protocol that Repetier firmware can use :)

[ebo]

Ah... OK. I need to make a run to the store to pick up food for the next couple of days, and I will take a poke at this tonight...

More later...

[ebo]

Earlier this week they released a new version of the Arduino IDE. I started by trying to upgrade to to 1.5.6-r2_beta on the off chance that there was some library which was pulled in and not fully a part of the repetier firmware. Unfortunately I spent hours fighting with updating an ebuild and getting it installed on my gentoo box. I'm going to have to put this aside probably until next weekend and see what my schedule allows.

[iXce]

Ok, let's see next weekend then :)

[ebo]

Sorry, I got hit with work and had to move on from this. It will be sometime next year before I can even look at this again.

[nicksears]

I have this same issue (I think). I'm trying to run Arduino-Due+Ramps-FD and have successfully compiled/uploaded Marlin for Due by bobc using arduino 1.5.8, but pronterface cannot connect. I've made sure I'm using the communication usb port on the Due and the correct com port on my PC when connecting via pronterface. I've tried with and without attaching the ramps-fd (mostly without) to isolate any issue from that hardware. I'm getting a post together cataloging what I've gone through trying to get this working so others can find it all in one place. Anyone found a solution for this?

[nicksears]

Found a solution (for me). I'll still be posting a summary soon, but for now the solution was uploading via arduino 1.5.6r2 (documentation says 1.5.x, but also says they were tested with 1.5.6r2) more to come.

[iXce]

Wow just changing the build environment fixes it ?

[nicksears]

I also uninstalled the boards drivers (and never reinstalled, it just shows up as abstract communication port) My second due is at work, I'll test it tomorrow before and after uninstalling the driver. Both PCs are Windows 8 and windows automatically installed those drivers.

On Mon, Oct 20, 2014 at 6:52 PM, Guillaume Seguin notifications@github.com wrote:

Wow just changing the build environment fixes it ?

— Reply to this email directly or view it on GitHub https://github.com/kliment/Printrun/issues/484#issuecomment-59858779.

Nick Sears, M.S. Graduate Research Assistant Biomedical Engineering Texas A&M University '10 832-289-5518

[nicksears]

Looks like it was the driver. It seemed like windows installed one (the official one as far as I knew) and I didn't go out of my was to install one after that but I was left with "USB Serial (Communication Class, Abstract Control Model) (COMX)"

You MUST connect at 115200 baud rate and or else you get a communication error, and you must use the programming usb port, not the native port, to connect.

I've posted at http://forums.reprap.org/read.php?1,291043,291043 and http://forums.reprap.org/read.php?13,244284 and http://andy-projects.blogspot.com/2014/02/ramps-fd-initial-setup.html?spref=tw about what I've found so far about RAMPS-FD if you are interested.

[iXce]

Okai, it definitely does not sound like a Printrun bug then ?

[nicksears]

I don't think so, but I haven't been able to reproduce the error since getting it to upload AND connect that first time. (it works with 1.5.6r2 and 1.5.8)

On Tue, Oct 21, 2014 at 6:13 AM, Guillaume Seguin notifications@github.com wrote:

Okai, it definitely does not sound like a Printrun bug then ?

— Reply to this email directly or view it on GitHub https://github.com/kliment/Printrun/issues/484#issuecomment-59912262.

Nick Sears, M.S. Graduate Research Assistant Biomedical Engineering Texas A&M University '10 832-289-5518

[ebo]

Just for completeness, can you once again go through and list your dependencies?

Pronterface/pronsole version Arduino IDE version compiler version OS make, model and version

I'm probably forgetting a couple like the version of the bintools (if you are using crossdev tools), but this would help me coolate the info in one place to give it a poke when I can break away some time.

EBo --

On Oct 22 2014 8:30 AM, nicksears wrote:

I don't think so, but I haven't been able to reproduce the error since getting it to upload AND connect that first time.

On Tue, Oct 21, 2014 at 6:13 AM, Guillaume Seguin notifications@github.com wrote:

Okai, it definitely does not sound like a Printrun bug then ?

— Reply to this email directly or view it on GitHub

https://github.com/kliment/Printrun/issues/484#issuecomment-59912262.

[nicksears]

I'm using the precompiled version of printrun from (http://koti.kapsi.fi/~kliment/printrun/) version 2014.03.10. I've tried Arduino IDE v1.5.6r2 and v1.5.8. Windows 8.1x64 pro

[ebo]

On Oct 22 2014 11:51 AM, nicksears wrote:

I'm using the precompiled version of printrun from (http://koti.kapsi.fi/~kliment/printrun/) version 2014.03.10. I've tried Arduino IDE v1.5.6r2 and v1.5.8. Windows 8.1x64 pro

Thanks. I run almost exclusively Gentoo Linu, but this gives me enough info to try to replace your setup.

Thanks!

EBo --

[rockstorm101]

I'm closing this issue. The root of the problem was found and it was not Printrun related.