RADDS work now stable with RepRap Firmware

Hi,

I using same version of printrun...

i have tried them both, i gave up on Radds/UDOO, although i suspect the UDOO board is the culprit. I received the DUET today and the serial communication is day and night difference.
The serial communication works as documented, whilst on the UDOO/RADDS combination my serial connection was always very irregular. Sometimes i couldn't connect at all, one hour later it worked perfect, and then the connection stopped again. Nothing repeatable, i tried for over a month, the UdooBunto beta2 was a littlebit more solid for its serial connection, but lacked in other area's, so i finally gave up, and ordered the DUET. Working like a charm, very happy

Quote
VDX
Hi Pieter,

have you tried with the images for "Debian Wheezy armHF" or "Ubuntu 12.04 LTS" ?

Quote
filipeCampos
Next printscreen is pronterface printing from an SD card, in the console it output no stop "Not SD printing", this is some bug?

FWIW, I opened an issue on this yesterday when I happened across it by chance in the source code,

https://github.com/dc42/RepRapFirmware/issues/15

Quote
dnewman

Quote
filipeCampos
Next printscreen is pronterface printing from an SD card, in the console it output no stop "Not SD printing", this is some bug?

FWIW, I opened an issue on this yesterday when I happened across it by chance in the source code,

https://github.com/dc42/RepRapFirmware/issues/15

@filipeCampos

I've posted a new rev of the RADDS build which corrects the inverted logic for the (deprecated) M27 command,

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09k-dc42-radds-b.bin

Thanks.

The new version correct the bug, but now is outputting lots of "SD Printing".

I checked the class GCodes to understand why is prints the same string during the print and the code is only processing to an request made. The problem is not the firmware but the successive request made my pronterface.

I do not know the reprap firmware, so far i only see the class GCodes by curiosity. The class is not correctly structured.
I not where to juggle or criticize, but this class have a lot of room to improve and need an major refactoring. There are function with more of 100 lines, lots of switch with other switch inside, no use of global variable like NEW_LINE = "\n" instead is repeated all over the code, all the string message must be put in other file and use set was a variable, etc..
The way the class was structured is very difficult to read and support.

Edited 1 time(s). Last edit at 10/21/2015 05:52PM by filipeCampos.

Quote
filipeCampos
Thanks.

The new version correct the bug, but now is outputting lots of "SD Printing".

I checked the class GCodes to understand why is prints the same string during the print and the code is only processing to an request made. The problem is not the firmware but the successive request made my pronterface.

Correct. For some reason pronterface keeps on sending M27 and so it keeps on getting back that response. It may be that pronterface is expecting some specific text string in the response and not seeing it. One would have to look at the pronterface code to tell.

Quote
filipeCampos
I do not know the reprap firmware, so far i only see the class GCodes by curiosity, but.. is a mess...
I not where to juggle or criticize, but this class have a lot of room to improve and need an major refactoring. There are function with more of 100 lines, lots of switch with other switch inside, no use of global variable like NEW_LINE = "\n" instead is repeated all over the code, all the string message must be put in other file and use set was a variable, etc..
The way the class was structured is very difficult to read and support.

First, I don't have a dog in this fight: I didn't write the RepRapFirmware code. That said, much of what you wrote above could be said about many firmwares. Look at Repetier for instance and ui.cpp. I've been a professional programmer for much of my life (1972 was when I first got paid to write some code, FORTRAN IV). There's lots of coding styles and people promoting this rule or that rule. They generally should be taken with a grain of salt. For example, there's nothing wrong in general with a subroutine which has more than 100 lines of code. Personally, I just ask that it be commented reasonably well or otherwise clear. Case statements within case statements are fine and pretty customary in some types of code such as state machines (e.g., parsers). That includes gcode parsers. Over generalization is sometimes silly, but lots of people engage in it -- often absent any real need to do so. (I'm often guilty of overgeneralizing code -- abstracting it too much.) I don't see anything terribly wrong with hardcoding LF (\n) everywhere or, if the person writing the code prefers, generalizing it. However, I'd be hard pressed to explain what purpose the generalization might serve in this case since it's well accepted that gcode uses LF as the line terminator. (I've not personally seen CR terminated gcode, but I suppose anything is possible.)

If I wrote the code myself, would I write it differently? Certainly! Would it be better? Very unlikely. Personally, I enjoy looking at code from other people and teams: it's how I learn new things, new ways of approaching a problem, and, in general, grow as programmer. Sure I see things that make me itch at times. Look at the firmware I maintain, Sailfish. Some of it is pretty ugly but that's sometimes the nature of the beast in code that has been worked on by lots of people. (It grew out of the Gen 3 RepRap firmware.)

Anyhow, I just thought I'd respond to your comment. I'm not myself offended in any way. Again, I didn't write the code you're refferring to. And I wouldn't be offended had you criticized code I had written.

Edited 1 time(s). Last edit at 10/21/2015 06:13PM by dnewman.

First, i sorry about the comments i made about the code. I know it was made by someone that have put lots of works and can very easy interpreted was an offence.

I understand your point of view and agree with some aspect, each person was is own programming style and no style must be considered was the one. Someone that defend only one style is like an religious fanatic.
But, there are some basic rules if respected will give lots of vantages, and my comment was to try to indicates these rules.

Like you, i m a software engineer with many years of experiences. In my job i do programming all day long and i like 3d printing because i do not need to do more programming...
So... the firmware work and is the only thing i need to know

Edited 1 time(s). Last edit at 10/21/2015 07:38PM by filipeCampos.

I have done some investigation. Pronterface sends M27 regularly if you check "Monitor status" in Options. It expects the response to contain the string "SD printing byte xxx/yyy" where xxx is the current file position and yyy is total number of bytes in the file, or something like that. I presume that is what Marlin or some other firmware sends.

The relevant code is line 1093-1094 and lines 1187-1194 in file pronterface.py. The simplest workarounds are not to check "Monitor status", or to comment out lines 1093-1094.

I will change the code in my fork of RepRapFirmware to send a response that Pronterface recognises. A better option would be for Pronterface to send M408 and parse the response, then it would have access to all the status information that PanelDue displays (and more) including the estimates of remaining print time.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi,

I will try to give an help about this M27 gcode command...

In the file pronterface.py the next line do the parsing of the expected response of the firmware:

if "SD printing byte" in l:
# M27 handler
try:
resp = l.split()
vals = resp[-1].split("/")
self.percentdone = 100.0 * int(vals[0]) / int(vals[1])
except:
pass

The firmware need to send an string with the next format:
"SD printing byte" + int number of the atual position you are reading from the sd file + "/" + int of total size of the file.
If the parsing fail, is send an exception an will output the total string the firmware was send. This is the reason is printing the "SD Printing".
Pronterface is doing an int casting, then the best is to send an integer and not a double or float. Not sure if will accept long value.

I think the correct is only send an string with the atual position in the file and the total file size, something like this:
"SD printing byte1/1024\n"

Edited 3 time(s). Last edit at 10/22/2015 09:32AM by filipeCampos.

Not sure if i wrong, but it appears that is not exist any standard and each printer server use is own rules.

It is possible to add an option in the firmware to indicate the "printer server/host" the user want to use?

The main idea is to allow to firmware to modify is behavior and adapt to the program is connected to.
For example, the user could indicate to the reprapfirmware it will communicate with pronterface or octoprint, etc..
It can be defined in the config.g file using an new gcode and be possible to modify in real time sending the gcode or using the lcd.
Implementing this feature in the firmware will allow to be 100% compatible with lots of server programs.

RepRapFirmware already has such a gcode, see [reprap.org].

I have already made the necessary change to return a compatible response when Marlin emulation mode is selected, and it will me in my next release.

Edited 1 time(s). Last edit at 10/22/2015 04:31PM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

> have already made the necessary change to return a compatible response when Marlin emulation mode is selected, and it will me in my next release.

And as the RADDS port is a fork of the dc42 branch, I generally have pulled and rebuilt things within a day or so of any updates. ("Day or so" highly dependent upon the nature of the changes in a dc42 update.)

very smart solution, instead of trying to adapt to the server you emulate an other firmware.

you can add an function that select the most compatible firmware mode for an list of servers. this way the user can select the name of the server programs and the firmware will set is compatible mode.
Most people including me do not know what is the compatible firmware for some programs.

Edited 1 time(s). Last edit at 10/22/2015 06:11PM by filipeCampos.

This weekend made more 2 prints using this new reprapFirmware.
In total i printed something like 25h and not found any problems...

7h print:
Dragon

8h print:
T800

So far the firmware have be very stable and produce good quality prints.
Pretty good job dnewman...

Edited 2 time(s). Last edit at 10/25/2015 02:38PM by filipeCampos.

Quote
filipeCampos
This weekend made more 2 prints using this new reprapFirmware.
In total i printed something like 25h and not found any problems...

7h print:
Dragon

8h print:
T800

So far the firmware have be very stable and produce good quality prints.
Pretty good job dnewman...

I'm glad you like it! RepRapFirmware was written originally by Adrian Bowyer, who of course has more experience of 3D printing than most people. It has been improved by a number of people including myself and Christian Hammacher. These days, I mostly look after the motion and the SD card interface, and Christian looks after the networking, web/FTP/Telnet interface and the print monitor. Our GCode interpreters have diverged somewhat. The credit for the RADDS port goes to Dan Newman.

I try to maintain RepRapFirmware's position as the leading firmware for delta printers, while also providing good support for Cartesian and CoreXY/CoreXZ printers. My own printers are a large delta (see link in my signature) and an Ormerod.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote
filipeCampos
This weekend made more 2 prints using this new reprapFirmware.
In total i printed something like 25h and not found any problems...

7h print:
Dragon

8h print:
T800

So far the firmware have be very stable and produce good quality prints.
Pretty good job dnewman...

Thanks for the followup and testing. It is appreciated! I've been working on built in LCD UI support. While it will not be as nice as having a PanelDue, it should prove useful to people who already have an LCD-based UI and who wish to move to RepRapFirmware with a minimum of disruption in their workflow. PanelDue is dc42's work and it is continuing to grow in functionality. Someone else has started a port of it to some different TFT LCD tech which, if it works out, will help to make it available to more people. (And yes, the PanelDue is presently supported by RepRapFirmware on RADDS. It's is documented in the repo and I've been using it for a couple of months now on my RADDS.)

When using RADDs with a Due do you get the faster USB with h/w flow control similar to what the Duet has?

Quote
WZ9V
When using RADDs with a Due do you get the faster USB with h/w flow control similar to what the Duet has?

You get the Arduino Due's native USB port which is the more robust of the two. How it compares to the USB on the Duet, I do not know. I believe it is identical, both being the native hardware USB supported by the SAM3X8E.

Quote
WZ9V
When using RADDs with a Due do you get the faster USB with h/w flow control similar to what the Duet has?

More specifically

• Duet: program via the native USB port; communicate with the running firmware via the native USB port. The native USB port is the only USB port on the Duet board.
• RADDS: Program via either the programming or native USB ports. Communicate with the running firmware via the native USB port (although you can compile it to use the programming port if you want). The Due has both USB ports physically present, native and programming. While you can program over the native USB port, it's difficult to do so once the RADDS is mounted to the Due as the ERASE button is covered.

So, for communicating with the firmware, you use the native USB port for both boards.

Edited 1 time(s). Last edit at 10/25/2015 09:23PM by dnewman.

I have noticed the upload of the firmware using the native usb is faster that using the programming one.

Normally in the others firmware is necessary to indicate the velocity of the communication, with the native usb this velocity is used? or it will be used the speed of the protocol USB 2.0?

Quote
filipeCampos
I have noticed the upload of the firmware using the native usb is faster that using the programming one.

Unless you will be downloading the firmware many times per day, does this really matter to you? And with the RADDS board, you can use either USB port. However, the physical design of the RADDS board will make it difficult for you to reach the ERASE button. If you use the native port to download firmware, then you will need some form of access to that button.

Quote
filipeCampos
Normally in the others firmware is necessary to indicate the velocity of the communication, with the native usb this velocity is used? or it will be used the speed of the protocol USB 2.0?

I'll leave that for someone more familiar with the Arduino API's implementation of I/O over the Due's "native USB" port to answer.

Quote
dnewman

Quote
filipeCampos
I have noticed the upload of the firmware using the native usb is faster that using the programming one.

Unless you will be downloading the firmware many times per day, does this really matter to you? And with the RADDS board, you can use either USB port. However, the physical design of the RADDS board will make it difficult for you to reach the ERASE button. If you use the native port to download firmware, then you will need some form of access to that button.

I have done several times the upload of the firmware with the native usb and without using the reset button.The same happens if you upload repetier firmware using the arduino IDE.
Why are you saying is necessary to push the erase button?

I was referring the different speeds between the native and programming usb not because of the upload velocity (this upload is done only sometimes), but because of the gain you can obtain when your have the board connected to an PC to control the printer. I print with pronterface (pc) because i do not have an lcd connected to the radds, I already tried both usb connections and not see any difference. I need to test the upload of a file to the sd card using both usb to check if there are the same speed.

Quote
filipeCampos
I have done several times the upload of the firmware with the native usb and without using the reset button.The same happens if you upload repetier firmware using the arduino IDE.
Why are you saying is necessary to push the erase button?

You may have the ports confused. With the programming port, it is not necessary to use either buttons. Since that matches your experience, it suggests you were using the programming port. Now it is my understanding and experience that to program over the native port, you must press the erase button first. See

http://playground.arduino.cc/Bootloader/DueBootloaderExplained

Also, keep in mind that you can set the baud rate for the native programming port with a M575 command

M575 P0 Bnnnn ; set baud rate of USB port to nnnn

You may need to research and experiment to see what baudrates you can use with the Due's native USB port. There have been a number of threads on the topic over at forum.arduino.cc.

I not confused... The programming board is near the power and native near the reset button.
I already done several times the upload of the reprapfirmware using the native and programming usb and never used the physical reset button (I do not have access because of the radds board).
The same goes to the repetier firmware, using the arduino IDE is possible to select the both arduino usb port. Both port allow to flash the firmware without the need to push the reset button.

This is the reason i not sure why you are referring the erase button. I have miss reading or missing something?
I can make an video to prove it if necessary...

Quote
filipeCampos
This is the reason i not sure why you are referring the erase button. I have miss reading or missing something?

Yes, see the link I provided a couple of posts up. It's a link to how the bootloader works on the Due. However, you may be using a method which is automatically asserting 1200 baud on the native USB port by briefly opening and closing it once. When that is done, the bootloader is enabled. On my genuine Due, I've found that to not work reliably but your mileage may vary. I certainly prefer to use the programming port.

As I posted previously, the bootloader is described at

http://playground.arduino.cc/Bootloader/DueBootloaderExplained

But perhaps more relevant is the bottom of this page,

https://www.arduino.cc/en/Main/ArduinoBoardDue

Scroll down to the section entitled, "Programming". If you assert 1200 baud, then you do not need to use the ERASE button.

But again, I don't really understand the point of this discussion. I do not understand why you are concerned about the speed of uploading firmware to the device. Has it been unacceptably slow for some reason? And if so, you might be better off taking such a concern to the Arduino forums since that would seem to be an Arduino Due issue in general and not specific to the RepRapFirmware. Also, the RepRapFirmware may be bigger than what you are used to uploading -- it's certainly bigger than Repetier and much bigger than your typical Due sketch. As such, it will necessarily take longer to upload, there being more of it. One of the reasons RRF is larger is that you do not do conditional compiles for different printer mechanics. Instead, at run time you tell RRF that your printer is a delta, a Core-XY, etc. So the code for the different mechanics are all present in a single binary. Much nicer that way; one less reason for novices to have to compile themselves (and potentially do something wrong).

Thanks for the info guys. I've decide to hold out for a Replicape and go in that direction. Until then I'll keep banging away on my Smoothie.

If the Arduino Due behaves like the Duet (and I have no reason to suppose that it doesn't, because the hardware is essentially the same), then the baud rate setting on the native port is not used. The baud rate setting is only used when the printer electronics uses a USB-to-serial converter to pass data to/from the MCU using one of its UARTs, as on Arduino Mega/RAMPS, and on the programming port of Arduino Due.

When passing data to the printer over USB, it is much better to use a native USB port than a USB-over-serial link. The native USB port drivers have built-in flow control. This means that you can configure the host program not to wait for the "OK" response after sending each command, and this hugely increases throughput in many cases, thereby avoiding "pause zits". Most of the major host programs (Repetier, S3D and even Pronterface now I think) have this option.

For programming, if you have both interfaces then use whichever one is more convenient.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi,

Thanks dc42 for the explanation of the usb port. From now i will use native port and remove the ok reply if possible.

I receive today the lcd send by angelo, installed but is not working with the reprapfirmware. On repetier the radds lcd works fine.
This reprapFirmware porting supports the radds 20x4 lcd? It is necessary to make some configuration?

PS: Thanks angelo for the hardware..

Quote
filipeCampos
I receive today the lcd send by angelo, installed but is not working with the reprapfirmware. On repetier the radds lcd works fine.
This reprapFirmware porting supports the radds 20x4 lcd? It is necessary to make some configuration?

As has been previously stated, the RepRapFirmware does not support a direct connect LCD UI. I've also stated that I have started work on a LCD UI for the RepRapFirmware on RADDS. However, it is not yet available.