Re purposing the Duet Ethernet board
-
Hi guys,
I represent a research group at an Australian University. We're looking at commercializing a product and are looking to save on development time. The Duet Ethernet appears to have all the hardware we need already built in a nice design.
Here is a list of what we're looking to achieve:
Drive up to 4 Stepper motors, 2 have their own independent drivers
Control two independent heat chambers.
Control CO2 levels. The CO2 sensor communicates using the RS485 protocol.
Drive a solenoid for CO2 flow
Drive an ultrasonic oscillator (this will likely have its own driver circuit and will only need an IO to control)
Drive 2 air pumps (potentially controlling using PWM or just IO)
Monitor Temperature and humidity via a single I2C sensor
Read up to 6 limit switches
Read 2 proximity sensors
Touch screen for monitoring and some controlCustom ethernet communication protocols are preferable however I'd be willing to adapt to the RepRap Gcode protocol if absolutely necessary.
Webserver for monitoring is a bonus
So my questions are:
- Do you think this board is capable of doing this? At a glance, I feel it can.
- How would we go about modifying the firmware to stray away from the RepRap firmware?
Cheers
-
That all sounds possible, except for RS485. What communications protocol does the RS485 device use? If it's standard async protocol then you could use a RS485 transceiver chip to convert it to 3.3V async protocol for one of the UARTs.
Regarding the temperature and humidity sensor, is the DHT22 suitable for you? That is already supported by RepRapFirmware. I caution against using I2C peripherals, because anything involving stepper motors generates a lot of noise, and the I2C bus is not tolerant of noise - it was intended to connect ICs together on the same PCB.
To modify RepRapFirmware, if it is acceptable for your product to run open source software then you can just fork the project on Github and change parts of it as needed.
-
Thanks for getting back to me! Yes, the RS485 is async so I'll just do up a little transceiver PCB to solve that problem.
The DHT22 just doesn't quite cut it for our application. We need something that can take the grunt of 90degC heat for a decontamination cycle. For the I2C problem, I was considering just using an I2C to RS485 transceiver on the sensor side and putting the two devices on the one bus. Do you see an issue with that?
I'm not too experienced in the structure of RepRap. Does RepRap that contains the low-level drivers such as stepper motor control, etc? Or is it built on top of the low-level drivers implemented by the designer?
Are you able to share or point us in the right direction to some of the low-level modules?
The main modules we'd be after are:
Stepper Drivers (functions such as move(distance) etc)
Ethernet drivers (basic TCP/IP comms that contain send/receive functions)Our end goal would be to scrap RepRap all together and write all our own control systems but it would be nice to base it off something first
We have an ATMEL-ICE for reprogramming the chip directlyReally appreciate the help!
Cheers -
A few comments:
- RRF does include the low level drivers for stepper motors. TCP/IP is handled by the W5500 chip on the Ethernet module.
- You don't need an Atmel ICE to load firmware. The simplest way to load firmware is to use the in-application programming facility, which allows you to upload new firmware through the web interface. If you can't do that, you can upload firmware through the USB port.
- Regarding two sensors on one RS485 bus, that's OK if the sensors play nicely together and you can tell which sensor each packet came from.
-
Thanks so much for your advice mate. Sounds like we have all the info we need.
Keep up the good work!
-
Hello again.
Regarding loading firmware...
As mentioned earlier, I'd like to eventually do away with the RRP. I've been playing around with the USB method of uploading firmware and have found it quite cumbersome. I've looked through the schematics and diagrams of the Duet Ethernet and can see that the JTAG interface is broken out but not populated. However on the actual board I have, I can't see anything related to JTAG at all that I can solder a header to.
Am I right in saying that the JTAG interface has been excluded from the production version all together therefore, I'm stuck with uploading via USB? Is there another way I can streamline uploading custom firmware to the board?
Cheers
-
We removed the JTAG connector, because we never used it and we needed the space to make routing changes to reduce EMI. If you only need a few Duets, there are still come around with the JTAG connector pads.
What do you find cumbersome about uploading via USB using Bossa?
-
I thought that might the case. I started using SAM-BA at first because I was already using it. However, I actually just investigated the BOSSAC method which is easily integrated into the IDE I'm using and it's made the development process much more bearable. Thank you
