Week 3 Experience and questions

I want to start by saying I just upgraded to 0.78f-dc42 from the stock firmware was I put on there during commissioning and it is like a new printer. for the first time I was confident to start a print while not in the same room and know it would be stuck to the bed when I got in there. so thanks @dc42


As the title suggests I have had my Ormerod for a few weeks now and have a couple of questions.
While looking through the SW model I noticed that there was two M3 Nylon washers between the X-carriage and the hot end mount the were not in the assembly instructions they seem like they would make the hotend less stable should they be installed?


My second question was regarding firmware.
Is there currently a way to use one of the other uarts on the duet as a g-code interface? having a look at the firmware it looks like I can duplicate platform::Getline serial port instead of the usbserial and then add it as a 4th interface in gcode::spin so I would have webserver, usb, serial, and file.

Hi zeb, I'm glad my firmware variant is working well for you.

I don't have any washers installed between the x-carriage and the nozzle mount, and I agree with you that they would make the nozzle mount less stable.

Regarding controlling the Ormerod via a serial interface, yes that would be entirely possible, but what would be the point? Do you have a device that you want to use to control the Ormerod that talks serial but not USB? In any case, you would need to add a driver chip to level-shift the signalling voltage from 3.3V to something suitable for use between devices.

I toyed with the idea of using the UTXD and URXD pins to connect my hot end board instead of using the analog z-probe and thermistor connections. I may still do this if I ever develop a hot end board for multiple nozzles.

---

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 dc42
Yep that is exactly the plan to make a equiv of the panelolu2 that has a 3.3v serial interface and sends gcodes to comunicate with the duet. I think this aproach would be inline with the current control methodology used by the web interface
Whats your opinion on this?

I know lvttl is not ideal between devices but the hmi would be mounted in close proximity to the duet. The other aproch would be to make a addon board which stacks on the duet or 4x and run 232 to the hmi

Edited 2 time(s). Last edit at 08/06/2014 04:50AM by zeb00.

If the device is mounted close to the Duet and powered from it, then using 3.3V TTL signals should be workable. You need to be careful because there may be noise on the ground pin, especially if you have a DueX4 connected as well.

It might even be possible to get the Panalolu2 working with the Duet, since the TWI pins are brought out both on the Duet expansion connector and the DueX4 expansion connector.

Yet another possibility is to have the Duet drive everything directly. A 128x64 GLCD using the ST7920 chip needs only 3 wires to drive it, and a rotary encoder needs only 2. Add 1 if you want a piezo sounder as well. That's 6 signals total. I believe that 20 out of the 22 signals on the DueX4 expansion connector are currently free.

The protocol used by the web interface provides considerably more functionality than the Gcode interface, so if you decide to go the serial route then duplicating the existing software for handling USB I/O might not be the best way to go.

btw a GLCD could look much nicer than the character-based display on the Panalolu2 because you can use different size fonts and proportional spacing.

Edited 1 time(s). Last edit at 08/06/2014 05:22AM 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
If the device is mounted close to the Duet and powered from it, then using 3.3V TTL signals should be workable. You need to be careful because there may be noise on the ground pin, especially if you have a DueX4 connected as well.

Yep agreed

Quote
dc42
It might even be possible to get the Panalolu2 working with the Duet, since the TWI pins are brought out both on the Duet expansion connector and the DueX4 expansion connector.

A good project for someone but not my cup of tea

Quote
dc42
Yet another possibility is to have the Duet drive everything directly. A 128x64 GLCD using the ST7920 chip needs only 3 wires to drive it, and a rotary encoder needs only 2. Add 1 if you want a piezo sounder as well. That's 6 signals total. I believe that 20 out of the 22 signals on the DueX4 expansion connector are currently free.

Didnt realy want to dig into the duet firmware that much and make another non standard version (when yours works so well allready)

Quote
dc42
The protocol used by the web interface provides considerably more functionality than the Gcode interface, so if you decide to go the serial route then duplicating the existing software for handling USB I/O might not be the best way to go.

Hmm ok may have to have another look though the source i figured there would be enough there but maybe not

Quote
dc42
btw a GLCD could look much nicer than the character-based display on the Panalolu2 because you can use different size fonts and proportional spacing.

yeah agree I just used panelolu2 as an example i was thinking something based on a KS0108B maybe Graphic LCD 128x64

Edited 1 time(s). Last edit at 08/06/2014 05:51AM by zeb00.

Yes a KS108 based GLCD is another possibility. I use ST7920 GLCDs instead because they have a lot fewer wires to connect.

---

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

Most of the firmware development I do at work is on boards that have a 3.3V serial port I use for debug purposes (115200 Bd 1 start, 8 data, 1 stop, no parity), and I routinely connect to my development boards via 1m long unshielded wires. Besides providing lots of textual debug output it is also sometimes used to transfer new firmware, and (touch wood) I have never noticed a single corrupted byte. As my debug output tends to be organised into neat columns, corrupt data would tend to be noticed. OTOH the boards are not switching or sharing power leads with high current devices.

Dave
(#106)

Edited 1 time(s). Last edit at 08/06/2014 12:47PM by dmould.