Recent aprinters does not work on udoo

[XayOn]

Hey there, I just tried older (thanks to firehopper) aprinter version.

With revision 18ea5c6dcc8ac6c70eea172df84013adeee6d943 it works perfectly (115200 freq), on master it does not work at all. Compiles but does not communicate.

I'm trying to get a few more information to make a proper bugreport, but in the meantime i'll be putting this here so other rampsfd+udoo users can just checkout that revision, build and upload

[ambrop72]

Since the referenced revision, native USB serial support has been implemented for Arduino Due and is used by default, and the programming port no longer works: https://github.com/ambrop72/aprinter/commit/d46f72dba036b45754174cce22ddc4e64d07ed82

Please confirm that this was your issue. Then I will close this since the programming port does not work by design. You need to use the native port for communication and the programming port only for flashing.

[XayOn]

"On ubuntu"... I meant "On udoo" on the title. Changed it.

[XayOn]

Isn't there a way to make it work with the programming port? Udoo does not have functional usb serial port on linux in their stuff. Allegedly they'll end up implementing it, but right now only android supported... and I'm not exactly sure if I'll be able to make the software work OK on android.

[ambrop72]

Oh, Udoo, that makes more sense ;)

There is a way to use the UART: change USE_USB_SERIAL to 0 in config/boards.sh, for the right target.

Or, if you're compiling with Nix, something like this (again for the right target) (note, I have just implemented this):

aprinterTestRadds = (aprinterTestFunc "radds" {}).override { forceUartSerial = true; };

[XayOn]

Thanks, compiling! Not using Nix, also, I'm using ramps-fd 1A, no radds =)

[XayOn]

Left it compiling. Will update tomorrow. If it works I'll post about it. Otherwise I'll have to make it work.

With older revisions I'm having troubles with the gcode parsing. I guess it's got to do with the encoding stuff. Read it was optional so I'll disable it for testing purposes.

Thanks El 24/09/2014 18:38, "Ambroz Bizjak" notifications@github.com escribió:

Oh, Udoo, that makes more sense ;)

There is a way to use the UART: change USE_USB_SERIAL to 0 in config/boards.sh, for the right target.

Or, if you're compiling with Nix, something like this (again for the right target) (note, I have just implemented this):

aprinterTestRadds = (aprinterTestFunc "radds" {}).override { forceUartSerial = true; };

— Reply to this email directly or view it on GitHub https://github.com/ambrop72/aprinter/issues/15#issuecomment-56698925.

[ambrop72]

If you're talking about the binary gcode format, note it affects only printing from sd card (and if you enable it you have to put encoded gcode on the sd card, it can't read plain gcode from sd card anymore).

[XayOn]

No sdcard on my system, that's not a problem. I feed it directly from udoo... But yes, I was talking about the binary stuff. When I input a binary gcode it gives a line numbering error (or sometimes just hangs) and when I put a normal gcode it gives a empty command foo

But don't have this in account yet, I'll come back tomorrow with more detailed data, a few tests done and something actually useful. El 24/09/2014 09:50, "Ambroz Bizjak" notifications@github.com escribió:

If you're talking about the binary gcode format, note it affects printing from sd card (and if you enable it you have to put encoded gcode on the sd card, it can't read plain gcode from sd card anymore).

— Reply to this email directly or view it on GitHub https://github.com/ambrop72/aprinter/issues/15#issuecomment-56736517.

[ambrop72]

Again, the serial interface doesn't support binary gcode. Also, you need to use an appropriate program to operate the serial interface (e.g. Pronterface/Pronsole). I don't know what you're doing, but if you're just "piping" data into the serial port, that won't work. That's because you need to wait for "ok" from the printer so you don't overflow it with data.

[XayOn]

El 24/09/2014 10:02, "Ambroz Bizjak" notifications@github.com escribió:

Again, the serial interface doesn't support binary gcode.

That makes sense, I think I misread that before, sorry.

Also, you need to use an appropriate program to operate the serial interface (e.g. Pronterface/Pronsole). I don't know what you're doing, but if you're just "piping" data into the serial port, that won't work. That's because you need to wait for "ok" from the printer so you don't overflow it with data.

No, no, of course not.

I'm using my octoprint fork (github.com http://github.com/dlabs-co/octoprint/ http://github.com/dlabs-co/octoprintdlabs http://github.com/dlabs-co/octoprint- http://github.com/dlabs-co/octoprintco http://github.com/dlabs-co/octoprint/ http://github.com/dlabs-co/octoprintoctoprint http://github.com/dlabs-co/octoprint) wich uses slicer to slice the STLs in a remote host (where I have a standard prusai3Steel configuration =) )

— Reply to this email directly or view it on GitHub.

[XayOn]

Changing monitoring state from 'Operational' to 'Printing' Send: N0M110_3 Send: N1G90_49 Send: N2G92 X0.00000_102 Send: N3G0 F999999.0_114 Send: N4G21_62 Send: N5M103_4 Recv: Error:empty command Changing monitoring state from 'Printing' to 'Error: empty command ' Recv: ok Recv: Error:empty command Recv: ok Recv: Error:Line Number is not Last Line Number+1, Last Line:0 Recv: ok Recv: Error:Line Number is not Last Line Number+1, Last Line:0 Recv: ok Recv: Error:empty command Recv: ok Recv: Error:empty command Recv: ok