RADDS work now stable with RepRap Firmware

Quote
dnewman

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.

Let me be more specific. The external, separate computer PanelDue touch screen LCD is supported by the RepRapFirmware on Duet and RADDS. How to connect it on the RADDS is documented in the RADDS fork of the dc42 RepRapFirmware: basically the top four pins of the AUX1 connector (GND, TX1, RX1, +5V).

A basic LCD + encoder UI driven by the firmware itself is not presently supported by the RepRapFirmware. Not on the Duet and not on RADDS. I have been working on a port of the Repetier LCD UI but have not finished it. So presently, Angelo's LCD board is not supported.

I have an strange problem and i do not know whats is the reason.

My radds + arduino due do not responde when i power up the printer for the first time. If i do an reset on the radds or arduino board then the radds start to work. If i shut down the printer and power up i the next 10 seconds then the radds start correctly. If i shut down and wait more of 10 seconds the problem happens.

At first i was almost sure the problem was the arduino due clone, i have buy a better one. I receive today and installed the arduino due with an new radds, but the problem still happens. So the problem is not the arduino or the radds boards.

The problem happens with reprapfirmware and repetier, is not an firmware problem
When the problem occurs the lcd was all 20x4 light up and make some noise. It was the same beaviour if the board was not firmware in the memory.

Is appears there are some booting problem with the board and is related with the power up of the arduino. The arduino is powered by the radds. The arduino for some reason do not start the firmware code.

Video explaining
[www.youtube.com]

Anyone have some idea of what it can be and help me to solve this?

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

... IIRC there was something with a capacitor on some Dues ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
VDX
... IIRC there was something with a capacitor on some Dues ...

You're not thinking of the auto-reset capacitor on Arduino Uno rev 2 which could lead to spurious behavior?

... dunno ... remembering something around RADDS and faulty Dues with inconsistent behaviour because of either wrong capacitors or 'glitches' from/through the voltage regulator ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

i have read in the arduino forum there is lots of person with this problem. it appears there are an arduino due r3-E version that solve this.
i have two arduino due r3 and both with the same problem, so is not an faulty board but an design error?

there are an firmware fix that suppose solve this, but is necessary to upload an new firmware in the 16u2 chip.

[forum.arduino.cc]

[forum.arduino.cc]

[forum.arduino.cc] -> post Nº10 there is an firmware of the 16u2 that fixe the problem, there are an user that have several due R3 board and confirmed the firmware have fixed this problem.

Edited 2 time(s). Last edit at 11/05/2015 04:51AM by filipeCampos.

After some investigation i found the cause is a bug of the firmware of the chip that controls the usb of the arduino due.
This problem is reported by some arduino user and there is an firmware that correct this.

To solve my problem it was necessary to uploaded the new firmware of the chip 16u2. I have uploaded, tested and confirmed it works one both my arduino due (blue china clone and black sainsmart).

The process is explain where:
[www.arduino.cc]

I have used an arduino mega that i was using before upgraded to the radds.
After the upload of the 16u2 chip it was necessary to upload again the firmware of the printer.

some photos of the process:

Very interesting. This isn't needed on the latest Due's, correct?

both by arduino due are recent and they are the version r3. the sainsmart was receive last week and i buy this one because i was thinking my blue arduino was faulty. after checked that both arduino due was the same problem and used 2 diferent radds 1.5 i understand it was not an hardware problem.

From i have read from my investigation all arduino due r3 have this problem and there is an new version called r3-e that do not have the problem.

resuming: if you buy an china clone like i have done, there is an good probability you have the same problem.

@dnewman: what is your arduino due version?

Hi there.

I 'm setting up RADDS for use with my CoreXY printer and I 've stumbled onto a problem with the thermistors.
No matter what I do, no thermistor works.
I 've tried 4 thermistors I have around, all 100K, none of them works.

Temperature fault on heater 0, sensor circuit is open/disconnected, T = -273.1
Temperature fault on heater 1, sensor circuit is open/disconnected, T = -273.1

I checked the RADDS board with a multimeter and found nothing of interest. I also confirmed the series resistors are 4K7.
I measured the A0 pin (testing for T0 thermistor) of the DUE at ambient temperature (~21C atm) and the voltage is 3.144V. The other thermistor pins which are unconnected read 3.284V. There's a ~140mV difference there which should be picked up by the 12-bit ADC but it obviously isn't for some reason...

I added some debug statements in Platform::getTemperature() to see what the ADC reads and it looks that, after averaging the values, it always reads 8190 (with 1-bit oversampling I suppose). This is larger than adDisconnectedVirtual and the heater is considered decoupled...

The only time I managed to make it read *some* value was when I connected a 10K pot in place of the thermistor and played with it.

My heaters section in config.g:

M305 P0 T100000 B3950 R4700 H0 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B3974 R4700 H0 L0	; Put your own H and/or L values here to set the first nozzle thermistor ADC correction

Any idea what to look for?

Edited 1 time(s). Last edit at 11/07/2015 10:39AM by mandrav.

Do you have the thermistors connected to the correct positions on the RADDS board? See

https://github.com/dcnewman/RepRapFirmware/blob/dev/doc/RADDS-v1.5.md#thermistors

On the RADDS 1.5 board, the bed thermistor (P0) goes to T4 on the RADDS board. The extruder thermistor (P1) goes to T0 on the RADDS board.

I think so, yes:



As I mentioned, I measured the voltages so I 'm pretty sure that plugging/unplugging T0 makes a difference in the voltage present on A0.

Also, what do you have for defining Tool 0 in config.g? A typical entry is,

; Tool definition
M563 P0 D0 H1       ; Define tool 0 (P0) using drive 0 (D0) and thermistor 1 (H1)
G10 P0 S0 R0        ; Set tool 0 (P0) operating (S0) and standby temperatures (R0)

From your photo, it looks like you are indeed using the correct positions on the RADDS board. If you talk to the RADDS board over the USB, you can send a bare "M305 P0" command and it will print out the settings for P0. You can repeat that for P1, "M305 P1". That will let you confirm that the M305 settings in your config.g have been processed.

Is the RADDS board being powered just from USB when you do this test or from the printer's power supply? I know that when I just power the board over USB, I sometimes see inaccurate temp reads owing to not enough current being supplied from the USB power source. (However, I don't recall ever seeing the reads completely fail in that situation.) This would especially be the case if you have RAPS-128 stepper drivers and have not yet put into config.g the commands to invert their enable. If that command isn't specified, then the steppers will enable and that will likely sag the 5V USB supply. However, I think your voltage reads would have indicated that more strongly (e.g., shown lower voltages).

Edited 1 time(s). Last edit at 11/07/2015 11:09AM by dnewman.

Output of "M305 P0":

T:100000.0 B:3950.0 R:4700.0 L:0.0 H:-100.0 X:0
ok

And output of "M305 P1":

T:100000.0 B:3974.0 R:4700.0 L:0.0 H:0.0 X:1
ok

Quote
dnewman
Is the RADDS board being powered just from USB when you do this test or from the printer's power supply?

No, connected to full 12V PSU.

Quote
dnewman
This would especially be the case if you have RAPS-128 stepper drivers and have not yet put into config.g the commands to invert their enable.

I have configured the motors as well as everything else. Actually, the movement is great. No, not great: amazing! I can't believe my eyes and ears

Thanks for trying to help me!

Quote
mandrav
Hi there.

I 'm setting up RADDS for use with my CoreXY printer and I 've stumbled onto a problem with the thermistors.
No matter what I do, no thermistor works.
I 've tried 4 thermistors I have around, all 100K, none of them works.

Temperature fault on heater 0, sensor circuit is open/disconnected, T = -273.1
Temperature fault on heater 1, sensor circuit is open/disconnected, T = -273.1

I checked the RADDS board with a multimeter and found nothing of interest. I also confirmed the series resistors are 4K7.
I measured the A0 pin (testing for T0 thermistor) of the DUE at ambient temperature (~21C atm) and the voltage is 3.144V. The other thermistor pins which are unconnected read 3.284V. There's a ~140mV difference there which should be picked up by the 12-bit ADC but it obviously isn't for some reason...

I added some debug statements in Platform::getTemperature() to see what the ADC reads and it looks that, after averaging the values, it always reads 8190 (with 1-bit oversampling I suppose). This is larger than adDisconnectedVirtual and the heater is considered decoupled...

The only time I managed to make it read *some* value was when I connected a 10K pot in place of the thermistor and played with it.

My heaters section in config.g:

M305 P0 T100000 B3950 R4700 H0 L0	; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 B3974 R4700 H0 L0	; Put your own H and/or L values here to set the first nozzle thermistor ADC correction

Any idea what to look for?

If you do the sums, you will find out that a 100K resistor (e.g. thermistor at 25C) connected with a 4.7K series a resistor should give a reading of about 7800, not 8190. So I don't think you can have the thermistor connected correctly.

---

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
dc42
If you do the sums, you will find out that a 100K resistor (e.g. thermistor at 25C) connected with a 4.7K series a resistor should give a reading of about 7800, not 8190. So I don't think you can have the thermistor connected correctly.

Hmm, when I connect the same thermistors on my Duet (even the RAMPS before that) they work just fine.
I have no cabling issues as far as I can tell (and the instruments I used to verify agree with me).

I even tried heating up one of the thermistors to see if anything would change and it did: at some point it started giving me some values. Probably wrong values but still...
One thing I forgot to mention is that I 'm using the dev tree of RRF from dnewman's github.

FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09j-dc42 ELECTRONICS: RADDS 1.5 DATE: 15/11/07

I can't dismiss though that it may very well be a blatantly stupid mistake on my part. That's why I 'm asking for help.
Any ideas welcome

Quote
mandrav
I even tried heating up one of the thermistors to see if anything would change and it did: at some point it started giving me some values. Probably wrong values but still...
One thing I forgot to mention is that I 'm using the dev tree of RRF from dnewman's github.

FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09j-dc42 ELECTRONICS: RADDS 1.5 DATE: 15/11/07

I can't dismiss though that it may very well be a blatantly stupid mistake on my part. That's why I 'm asking for help.
Any ideas welcome

I'm using that rev with no issues as are some other people. I see that you compiled yourself, so just to be sure, I just rebuilt and reloaded it on my CoreXY printer,

Send: M115
Recv: FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09j-dc42 ELECTRONICS: RADDS 1.5 DATE: 15/11/07
Send: M305 P0
Recv: T:100000.0 B:4066.0 R:4700.0 L:0.0 H:0.0 X:0
Send: M305 P1
Recv: T:100000.0 B:4066.0 R:4700.0 L:0.0 H:0.0 X:1
Send: M105
Recv: ok T:17.0 B:17.2
Send: M105 S3
Recv: ok {"status":"I","heaters":[17.2,17.1],"active":[0.0,0.0],"standby":[-273.1,0.0],"hstat":[2,2],"pos":[0.00,0.00,0.00],"extr":[0.0],"sfactor":100.00,"efactor":[100.00],"tool":0,"probe":"0","fanRPM":0,"homed":[0,0,0],"message":"","geometry":"coreXY","myName":"CoreXY"}

You did notice that your "M305 P0" output showed "H-100.0" and not "H0.0"? That's the bed thermistor.

[Side note: that firmware rev is actually 1.09k not the 1.09j shown in the M115 output. Mistake on my part in my fork of the repo which I'll fix.]

And since you appear to have compiled yourself, you might want to try a .bin file from my github repo and see if that makes a difference. E.g.,

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


If it does, we can then discuss what might be different about your build environment (e.g., patches missing for Arduino APIs).

Edited 1 time(s). Last edit at 11/07/2015 12:29PM by dnewman.

Quote
dnewman
You did notice that your "M305 P0" output showed "H-100.0" and not "H0.0"? That's the bed thermistor.

Yes, this was after trying many things
It's H0 in my config,g.

Quote
dnewman
And since you appear to have compiled yourself, you might want to try a .bin file from my github repo and see if that makes a difference.

I have tried with RepRapFirmware-1.09k-dc42-radds-a.bin but I will try the one you linked right away.

Quote
mandrav
I have tried with RepRapFirmware-1.09k-dc42-radds-a.bin but I will try the one you linked right away.

No change with the one you linked too...

Quote
mandrav
I have tried with RepRapFirmware-1.09k-dc42-radds-a.bin but I will try the one you linked right away.

Then I suspect that later builds will not make a difference. Nothing has significantly changed and it's common code with the Duet board. All that differs is the pin assignments for the thermistor signals and the number of available temp sensors. This is a RADDS v1.5 board and not an earlier board? I do know that changes associated with thermistor read stability were made between 1.5 and earlier boards. However, I do not know if those were merely electrical and layout changes or if they also involved changing pin assignments as well. If this is a RADDS 1.5 board, then I'm stumped.

BTW, I've been assuming that the thermistor pin assignments were different on one or more older versions of RADDS as I've seen versions of Repetier which have RADDS thermistor pins assignments which do not agree with the RADDS v1.5 schematics.

This is a RADDS v1.5 board, at least that's what it says on the bottom side.
I will try some more debugging.

If I put a 5K6 resistor in place of the thermistor, the "temp" reads 40C. Is that about right or is it totally off?

Quote
mandrav
If I put a 5K6 resistor in place of the thermistor, the "temp" reads 40C. Is that about right or is it totally off?

That is way off, the temperature reading should be much higher. It sounds to me that your thermistor series resistors are a lot lower than 4.7K, or they are connected to +5V instead of +3.3V, or the analog reference voltage on your Due is a lot lower than 3.3V.

---

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
dc42

Quote
mandrav
If I put a 5K6 resistor in place of the thermistor, the "temp" reads 40C. Is that about right or is it totally off?

That is way off, the temperature reading should be much higher. It sounds to me that your thermistor series resistors are a lot lower than 4.7K, or they are connected to +5V instead of +3.3V, or the analog reference voltage on your Due is a lot lower than 3.3V.

Yes, that's what I suspected.
Looks like I may have problematic Due in my hands.
I removed the RADDS board and loaded the simplest analogRead sketch which just looped around reading A0 and displaying its value through serial every 250ms.
I then put an external 3.3V on A0 from my lab psu.
Result? It was reading 4095 until I lowered the voltage on A0 to ~1.9V
Looks like I have to buy a new Due...

Thanks dnewman and dc42 for the help though!

Don't know about the Due, but you can specify the AD-reference voltage on all 8-bit arduinos with "analogReference()"
Maybe it isn't set right in your simple test program?
-Olaf

Quote
o_lampe
Don't know about the Due, but you can specify the AD-reference voltage on all 8-bit arduinos with "analogReference()"
Maybe it isn't set right in your simple test program?
-Olaf

I haven't delved too deep into Due development but it looks like analogReference isn't supported on the Due?
Besides, I 'm having the exact same problem with RRF, that's why I tried to make a minimal sketch to isolate the problem.

Thanks for the input Olaf

Quote
mandrav
I haven't delved too deep into Due development but it looks like analogReference isn't supported on the Due?

For some definition of "supported" it is supported but it is effectively a no-op. That is, the routine is declared in wiring_analog.h and code for it exists in wiring_analog.c which then sets a variable named analog_reference. However, that variable is not referenced anywhere else in the Due Arduino API sources. So, it is initialized at compile time to AR_DEFAULT, can be changed via analogReference(), but is use nowhere else in the code. That in contrast to the AVR Arduino API sources which do make use of it in analogRead().

Quote
dnewman

Quote
mandrav
I haven't delved too deep into Due development but it looks like analogReference isn't supported on the Due?

For some definition of "supported" it is supported but it is effectively a no-op. That is, the routine is declared in wiring_analog.h and code for it exists in wiring_analog.c which then sets a variable named analog_reference. However, that variable is not referenced anywhere else in the Due Arduino API sources. So, it is initialized at compile time to AR_DEFAULT, can be changed via analogReference(), but is use nowhere else in the code. That in contrast to the AVR Arduino API sources which do make use of it in analogRead().

Yes, actually, having a quick glance over the SAM3X datasheet, it looks like its ADC is always referenced against the voltage present on the ADVREF pin (physical pin 53).
With that info I have successfully managed to trace down the problem in a jumper resistor on the Due which was supposed to be 0 ohms but apparently it wasn't and it caused a voltage drop of 1.4 volts (hence the 1.9V I had to go down to so the ADC would start converting "correctly")!
In other words: problem fixed by replacing the jumper resistor (JR1 for those interested) with another 0 ohms one