Duet 0.8.5 with E3D PT100 sensor+amplifier ?

Quote
dc42

Quote
Crispy001
Unfortunately I doubt this relationship is linear, so I'll be hooking this up to a stable 5v supply and plan on keeping my heaters below 600C!

Bad idea. If you do that, then the reading you get will vary with the ratio between the actual voltage on the 5V supply and the actual voltage on the 3.3V supply. If you power the amplifier from 3.3V instead, then it will not be sensitive to the exact supply voltage, because both the amplifier and the ADC are ratiometric and will be using the 3.3V supply as the reference.

I understand, but I'd think to run the board at 3.3v, I'd need to generate a new lookup table to account for any introduced nonlinearity. However, I don't believe I possess the appropriate hardware to take measurements accurate enough to make a new table.

What I can do is watch the supply voltages and see how much they vary under different conditions. If the variance is small, I see no issue in continuing this way.

What would you do?

Quote
Crispy001
What would you do?

You will not get dependable results if you power the PT100 amplifier from 5V and feed it to controller electronics whose ADC is referenced to 3.3V. OTOH, if the amplifier operates properly from 3.3V, then the output voltages will be 3.3/5 times the values they give in the table.

Personally, I would make or buy a PT100 interface board based on the MAX31865 chip. That would avoid any issues with supply voltage, ground noise, or ADC offset. I have greatly respect for E3D, however they seem reluctant to acknowledge 32-bit controller electronics (which invariably uses 3.3V power and ADC reference) and the associated modern firmwares for them. The potential accuracy of the PT100 is in part wasted if you use an analog signal processing chain right through to the controller electronics, instead of early conversion to digital as the MAX31865 does. The problem is compounded by the lack of a separate analog ground connection on Arduino/RAMPS and some other electronics boards.

---

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
Crispy001
What would you do?

then the output voltages will be 3.3/5 times the values they give in the table.

If you suspect this relationship will remain true for 100-300c, then I'll switch my wiring over and give it a go. I'll see if I can wire up a secondary thermocouple for testing purposes to ensure the values land where they should. I'm more concerned with consistency than accuracy, and I suspect this solution may do better here.

Also, thanks for your detailed responses! I haven't looked at the end stop portion of the schematic yet, but I'm assuming these are 3.3v as well?

Yes the Duet endstop connections are 3.3V too. Some optical endstops don't have enough current sink capacity for Duet or Smoothieboard when powered from 3.3V. This can generally be fixed by changing the LED series resistor on the endstop.

---

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].

My intention is to move the three temperature inputs I'd need to the expansion header so as to avoid the pull up resistors. AD0, 10, and 11 are my chosen candidates. I have no plans for using the duex4 or paneldue, so this seems like a safe move. However, I still need to modify the temperature code to use the E3D provided lookup table instead of thermistor datasheet values. Looks like the place to do this is the "Thermal Settings" section of Platform.cpp. Hopefully I'll have time to test out some changes and report back in a day or two.

I'm not the greatest coder in the world, but if this results in a solution worth sharing, I'll document accordingly after I get my new printer running.

I've modified the code but I can't seem to get things to compile after following the steps here. I get a "build finished" confirmation but my Releases folder contains no .bin to upload to the board. This is with Eclipse C/C++ 4.5.1 with the Arduino 2.2.0.1 eclipse add-on and Arduino 1.5.8 installed. Older or newer versions of the Arduino IDE failed to compile entirely. Any thoughts? Spent half an hour on the code and 6 hours trying to get it compiled--extremely frustrating.

Post your build log (especially the last 50 or so lines), then we can see whether it is doing the right steps.

---

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].

The issue I was encountering was related to not having the paths and supporting files set up properly for the compiler. I fixed that problem, but now I'm encountering the below error on compile. I didn't touch these variables or functions whatsoever; the code was pulled 10/31.

../Platform.cpp: In member function 'void Platform::Init()':
../Platform.cpp:184:2: error: 'maxStepperDACVoltage' was not declared in this scope
  maxStepperDACVoltage = MAX_STEPPER_DAC_VOLTAGE;
  ^
../Platform.cpp: In member function 'void Platform::UpdateMotorCurrent(size_t)':
../Platform.cpp:1388:76: error: 'maxStepperDACVoltage' was not declared in this scope
   unsigned short dac = (unsigned short)((0.256*current*8.0*senseResistor + maxStepperDACVoltage/2)/maxStepperDACVoltage);
                                                                            ^
../Platform.cpp: In member function 'void Line::Write(char, bool)':
../Platform.cpp:2511:37: error: 'class Stream' has no member named 'canWrite'
    if (outputNumChars == 0 && iface.canWrite() != 0)
                                     ^
../Platform.cpp: In member function 'void Line::TryFlushOutput()':
../Platform.cpp:2565:38: error: 'class Stream' has no member named 'canWrite'
  while (outputNumChars != 0 && iface.canWrite() != 0)
                                      ^
subdir.mk:130: recipe for target 'Platform.cpp.o' failed
make: *** [Platform.cpp.o] Error 1

Edited 2 time(s). Last edit at 11/29/2015 01:47AM by Crispy001.

1. Check your Platform.h file. MAX_STEPPER_DAC_VOLTAGE is defined around line 96.

2. You need to copy the files in the ArduinoCorePatches folder over the corresponding files in your Arduino 1.5.8 installation. That will deal with the 'canWrite' error.

Edited 1 time(s). Last edit at 11/29/2015 02:29AM 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].

Good news and bad. Good news is I was able to get the code compiled and uploaded based on your feedback (many thanks DC42!). The bad news is the duet won't boot when the E3D PT100 sensor is powered from 3.3v--I measured 0.74v on the 3.3v line while the sense line was disconnected, which would explain the boot failures. The reason why this voltage drop is happening is what concerns me. I've double checked the wiring and it looks good. Both sensor boards I have exhibit the same behavior. I'm unsure if the current draw is too much for the TC2117-3.3VDBTR or if something else is going on. I'll investigate more in the morning.

Edited 1 time(s). Last edit at 11/29/2015 06:09AM by Crispy001.

Turns out I had the sensors wired to the reset pin, not the 3.3v pin. Should have things running today.

Decided to grab the latest from your fork and there's a compile error for no type definition for OutputPin. Figured as long as I'm flashing the board I might as well have the latest.

In file included from ../RepRapFirmware.h:118:0,
                 from ../DDA.cpp:8:
../Platform.h:674:3: error: 'OutputPin' does not name a type
   OutputPin stepPinDescriptors[DRIVES];   // output pin descriptors for faster access, with the driver number mapping already done

[github.com]

---

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
[github.com]

Thank you once again for your help. I kept working on the older version for the sake of not complicating things any further. Sadly, I haven't been successful yet.

I'm using two different types of temperature sensors, a type-k thermocouple with AD4985 amp for the heated bed, and the E3D PT100 combo x2 for dual hotends. As far as I can tell, the sensors work perfectly, I just need the Duet to cooperate.

I changed the temp pins (#define TEMP_SENSE_PINS) to 7, 8, 9 for AD0, AD10, and AD11 on the expansion header and modified the GetTemperature function in platform.cpp to output the raw adc values while debugging so I could see what was going on. M105 gives an erroneous value for the bed and no values whatsoever for the hotends. The web interface also shows error for the hotends. I referred to this for the expansion pinout and I'm confident the sensors are hooked up to the right pins. Any ideas towards what I might've missed? I don't feel like moving the sense pins to the expansion header should be causing this behavior.

If the above gets solved, the code for the new sensors is pretty simple--my main concern is where to apply one curve for the bed and the other for the hotends. I don't fully understand the size_t input argument for GetTemperature and my initial attempts to if/else my way to victory were unsuccessful.

float ad4985calculatedtemp = ((reading-1.25)/0.005);	// Calibration curve provided by Adafruit (volts->deg C)
float pt100calculatedtemp = ((21.069*(reading*reading))+(177.95*reading)-220.37); // Polynomial curve generated from E3D lookup table (volts->deg C)

Overall I feel like I'm in over my head on something trivial.

I switched to the nightly build of the Arduino plugin and spent some time experimenting with different versions of the Arduino IDE. I believe I broke my toolchain somewhere along the line in my previous attempts, complicating matters. I'm now able to compile 1.09m successfully with IDE 1.5.8, but the duet won't connect with Pronterface when I do so. Your 1.09m .bin file works great, so I'm thinking the hardware is still good. My bin file is 104 bytes smaller, so something must be missing.

Using the 1.6.5 IDE created quite a few errors on compiling--possibly due to compiler arguments as I'd think the code from Arduino should compile. What version of the IDE, and what compiler input arguments do you use? Have you made any additional patches to the Arduino library files that aren't included in the package?

Error example (1.6.0)

C:\arduino-1.6.0\hardware\arduino\sam\cores\arduino/USARTClass.h:112:49: error: 'UARTModes' does not name a type
     void begin(const uint32_t dwBaudRate, const UARTModes config);
                                                 ^
C:\arduino-1.6.0\hardware\arduino\sam\cores\arduino/USARTClass.h:112:59: error: ISO C++ forbids declaration of 'config' with no type [-fpermissive]
     void begin(const uint32_t dwBaudRate, const UARTModes config);
                                                           ^
subdir.mk:132: recipe for target 'Line.cpp.o' failed
make: *** [Line.cpp.o] Error 1

Edited 2 time(s). Last edit at 12/07/2015 12:53AM by Crispy001.

Currently I use Arduino 1.5.8 with the patches from my RepRapFirmware repo applied. I haven't tried a more recent version. I intent to rewrite the hardware layer to avoid the Arduino core completely and use the underlying ARM libraries instead.

Use a file compare tool to compare your binary and mine. There are some strings in the binary that depend on the path to the build area, which may account for some of the difference in size.

Here is a typical command line showing the C++ compiler options.

'Building file: ../RepRapFirmware.cpp'
'Starting C++ compile'
"C:/Arduino-1.5.8/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -std=gnu++11 -O2 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -mcpu=cortex-m3 -DF_CPU=84000000L -DARDUINO=158 -DARDUINO_SAM_DUE -DARDUINO_ARCH_  -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/libsam" "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/CMSIS/CMSIS/Include/" "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/CMSIS/Device/ATMEL/"   -I"C:\Arduino-1.5.8\hardware\arduino\sam\cores\arduino" -IC:/arduino-1.5.8/hardware/arduino/sam/system/libsam/include -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\EMAC" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\Lwip" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\MCP4461" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SamNonDuePin" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SD_HSMCI" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SD_HSMCI\utility" -I"C:\Arduino-1.5.8\hardware\arduino\sam\libraries\Wire" -I"C:\Arduino-1.5.8\hardware\arduino\sam\variants\arduino_due_x" -I"C:\Arduino-1.5.8\hardware\tools\gcc-arm-none-eabi-4.8.3-2014q1\lib\gcc\arm-none-eabi\4.8.3\include" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\Flash" -MMD -MP -MF"RepRapFirmware.cpp.d" -MT"RepRapFirmware.cpp.d" -x c++ "../RepRapFirmware.cpp"  -o  "RepRapFirmware.cpp.o"   -Wall  -O2 -std=gnu++11
'Finished building: ../RepRapFirmware.cpp'

Edited 1 time(s). Last edit at 12/07/2015 03:59AM 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].

Quote
dc42
Currently I use Arduino 1.5.8 with the patches from my RepRapFirmware repo applied. I haven't tried a more recent version. I intent to rewrite the hardware layer to avoid the Arduino core completely and use the underlying ARM libraries instead.

Use a file compare tool to compare your binary and mine. There are some strings in the binary that depend on the path to the build area, which may account for some of the difference in size.

Here is a typical command line showing the C++ compiler options.

'Building file: ../RepRapFirmware.cpp'
'Starting C++ compile'
"C:/Arduino-1.5.8/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/arm-none-eabi-g++" -c -g -std=gnu++11 -O2 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -mcpu=cortex-m3 -DF_CPU=84000000L -DARDUINO=158 -DARDUINO_SAM_DUE -DARDUINO_ARCH_  -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/libsam" "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/CMSIS/CMSIS/Include/" "-IC:/Arduino-1.5.8/hardware/arduino/sam/system/CMSIS/Device/ATMEL/"   -I"C:\Arduino-1.5.8\hardware\arduino\sam\cores\arduino" -IC:/arduino-1.5.8/hardware/arduino/sam/system/libsam/include -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\EMAC" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\Lwip" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\MCP4461" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SamNonDuePin" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SD_HSMCI" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\SD_HSMCI\utility" -I"C:\Arduino-1.5.8\hardware\arduino\sam\libraries\Wire" -I"C:\Arduino-1.5.8\hardware\arduino\sam\variants\arduino_due_x" -I"C:\Arduino-1.5.8\hardware\tools\gcc-arm-none-eabi-4.8.3-2014q1\lib\gcc\arm-none-eabi\4.8.3\include" -I"C:\Users\David\Eclipse\RepRapFirmware\Libraries\Flash" -MMD -MP -MF"RepRapFirmware.cpp.d" -MT"RepRapFirmware.cpp.d" -x c++ "../RepRapFirmware.cpp"  -o  "RepRapFirmware.cpp.o"   -Wall  -O2 -std=gnu++11
'Finished building: ../RepRapFirmware.cpp'

I purged all my old Arduino files, deleted the old project, and re-setup everything. I'm using MinGW and it appears to be version 4.8.1, could this be the problem? I'll see if I can update to 4.8.3 to match the Arduino version. I get the following error on compile with gcc 4.8.1, Arduino 1.5.8, Eclipse Mars 4.5.1, 2.4.0 12/6/15 nightly build of the Eclipse Arduino extension. I didn't see this in your arguments so I'm hesitant to add it without checking.

Update: 4.8.3 had no effect.

"C:/arduino-1.5.8/hardware/tools/gcc-arm-none-eabi-4.8.3-2014q1/bin/arm-none-eabi-gcc" -c -g -Os -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -Dprintf=iprintf -mcpu=cortex-m3 -DF_CPU=84000000L -DARDUINO=158 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM  -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSB_MANUFACTURER=\""Unknown"\" -DUSB_PRODUCT=\""Arduino Due"\" "-IC:/arduino-1.5.8/hardware/arduino/sam/system/libsam" "-IC:/arduino-1.5.8/hardware/arduino/sam/system/CMSIS/CMSIS/Include/" "-IC:/arduino-1.5.8/hardware/arduino/sam/system/CMSIS/Device/ATMEL/"   -I"C:\arduino-1.5.8\hardware\arduino\sam\cores\arduino" -IC:/arduino-1.5.8/hardware/arduino/sam/system/libsam/include -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\EMAC" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\Lwip" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\MCP4461" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\SamNonDuePin" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\SD_HSMCI" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\SD_HSMCI\utility" -I"C:\arduino-1.5.8\hardware\arduino\sam\libraries\Wire" -I"C:\arduino-1.5.8\hardware\arduino\sam\variants\arduino_due_x" -I"C:\Arduino-1.5.8\hardware\tools\gcc-arm-none-eabi-4.8.3-2014q1\arm-none-eabi\include" -I"C:\Users\Crispy\workspace\RepRapFirmware\Libraries\Flash" -MMD -MP -MF"Libraries/SD_HSMCI/utility/hsmci.c.d" -MT"Libraries/SD_HSMCI/utility/hsmci.c.o" -D__IN_ECLIPSE__=1 "C:/Users/Crispy/workspace/RepRapFirmware/Libraries/SD_HSMCI/utility/hsmci.c"  -o  "Libraries/SD_HSMCI/utility/hsmci.c.o"   -Wall  -O2
C:/Users/Crispy/workspace/RepRapFirmware/Libraries/SD_HSMCI/utility/hsmci.c: In function 'hsmci_get_response_128':
C:/Users/Crispy/workspace/RepRapFirmware/Libraries/SD_HSMCI/utility/hsmci.c:427:2: error: 'for' loop initial declarations are only allowed in C99 mode
  for (uint8_t i = 0; i < 4; i++) {
  ^
C:/Users/Crispy/workspace/RepRapFirmware/Libraries/SD_HSMCI/utility/hsmci.c:427:2: note: use option -std=c99 or -std=gnu99 to compile your code
Libraries/SD_HSMCI/utility/subdir.mk:87: recipe for target 'Libraries/SD_HSMCI/utility/hsmci.c.o' failed
make: *** [Libraries/SD_HSMCI/utility/hsmci.c.o] Error 1

Edited 2 time(s). Last edit at 12/07/2015 11:40PM by Crispy001.

You need to change the flags setting when compiling C files, to select C99 mode. My computer is down right now so I can't check the setting, but afair it's -std=c99 or something similar.

---

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].

-std=gnu99 did the trick. I'll upload the binary tonight and see if we can put this stage behind us. Thanks a bunch.

Interesting news! The code compiles and uploads fine...but I still can't connect with Pronterface. However, I can confirm through the web control interface that the board is booting and polling temperatures correctly. I'm not sure how that could happen, but it's functional enough that I think I could get by.

I plan to investigate if something is amiss with the ftdi driver that might be to blame.

Edited 1 time(s). Last edit at 12/09/2015 02:49PM by Crispy001.

Success! I have both the ad8495 with k thermocouple and the e3d pt100 sensors working. I still need to do some testing to make sure things are good, after which I'll document the changes in case anyone else wishes to do the same.

I also reloaded the ftdi driver with no effect on the Pronterface connection problem.

Edited 2 time(s). Last edit at 12/10/2015 06:45PM by Crispy001.

I don't know that you will care, but if you go back to older versions of my repo (builds for RADDS and Duet), you'll find AD8495 support,

https://github.com/dcnewman/RepRapFirmware/blob/a5bc5835dbe3f5ee91d27ca1a29b1807436f6531/src/Platform.cpp#L1356

I removed it and left in just the MAX31855 support. I had the AD8495 support there for testing by myself and one other individual until such time that I could get around to testing and finishing the MAX31855 support.

Thanks, I'll take a look. You also helped me notice I wrote ad4985 instead of the correct ad8495.

Printer is running and working quite well for a new build, thanks folks. What should my start gcode look like to run leveling? Should I just execute a G32 every print? Do I need a bed.g file for an H-gantry setup?

Personally, I never use auto leveling on my CoreXY bots. Rather, I build them such that they maintain level over many months and many removal and replacements of the build plate. The same should be achievable on an H-gantry setup.

Quote
dnewman
Personally, I never use auto leveling on my CoreXY bots. Rather, I build them such that they maintain level over many months and many removal and replacements of the build plate. The same should be achievable on an H-gantry setup.

I suppose I could do that, but I already have the hardware (IR ala DC42) for it so I'll keep it in! This is the first printer I've built with aluminum extrusion, the difference in frustration and performance is amazing. Now I just need to get the enclosure together and tidy things up!

Quote
Crispy001
Printer is running and working quite well for a new build, thanks folks. What should my start gcode look like to run leveling? Should I just execute a G32 every print? Do I need a bed.g file for an H-gantry setup?

Yes you can use a bed.g file for bed compensation. See [reprap.org] and adjust the coordinates of the 5 probe points to suit your build.

On my Ormerod I have the bed sufficiently level that I do not need to use bed compensation except when doing large prints. I still use the IR sensor to do Z homing at the centre of the bed before each print but after the printer has heated up, so that I get an accurate Z=0 height. For large prints I do run G32 before the print, because there is a slight twist in the Y axis that I haven't corrected yet.

---

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 all,

Little late to this but the PT100 subject matter caught my eye, I have worked with PT100 and PT1000 before so this might help some of you.

I made a quick a dirty circuit for a PT100 based on 3V, this is based on a 0 to 300C temperature range and produces a nice linear output. The circuit image is below, as well as an Orcad simulation output.



The PT100 resistance range is shown on the x axis, 100 ohms is 0C and ~212 ohms is 300C



Additional items not added would be some decoupling capacitors, possibly a low pass filter on the output. The resistor values are all common except for R5 and R3, but I chose these as both available in through+hole or SMD from Farnell. The opamp is a Texas Instruments rail to rail, this should suffice for this but there are better suited options (has to be rail to rail though).

To improve the accuracy a PT1000 would be a better option if you have a long cable, but PT100 are readily available fitted in small metal cans on Ebay.

Hope this is of use to someone,

Ant

Edited 1 time(s). Last edit at 02/06/2016 11:53AM by Antscran.

---

[www.coder-tronics.com]
[www.thingiverse.com]