Topics created by croadfeldt

A plain G30 command doesn't do any XY movement, it probes at the current XY coordinates and sets the Z height.

RE: Multiple devices using DWC - OK, that probably it, as I have multiple machines monitoring print status via DWC. Will drop to one in the meantime. Thanks Dave!

To finish off this thread. I rewired the leads from the Power supply to the duetwifi and duex5. Used the 12 volt connections from the atx female connector attached to the atx male connector from the PS and then some PCIe 12 volt lines for the bed and finished it off by attaching another 12volt plug to the sata / molex ports on the PS. The 5vsb remained for powering the DuetWifi.

After that cleanup work and using additional 12v connections to the PS, everything is stable now and working as expected. 12v readings never dip below 11.5 and rarely go below 11.6/7 when printing, the bed is on and the hot end is on. I'd call this done.

The only reamining issue is the part cooling fan that surges based on the requested fan %. The higher the percent, the shorter the interval between surging. A quick M106 F200 clears it up though.

Thanks for your hep!

Ugh, spoke too soon evidently. What I thought was a fix or work around turned out to be false. The issue persists. Will do more troubleshooting tomorrow.

UPDATE - RESOLVED:

Short Version: 3rd party ribbon cable used for Duex5 was causing problems, suspect voltage drop.

Long Version:

After another couple of weeks, the issue spread to attempting to boot with USB connected as well. Connected the DuetWifi to a known good USB3 port on a windows system to update the firmware. Did so successfully, then after hitting the reset button, followed firmware instructions to a T, the DuetWifi went into a reboot cycle. It was cycling about 1 - 1.5 times per second.

After some more troubleshooting, I identified that the longer ribbon cable I used to connect my Duex5 was causing the reboot cycle in some fashion. Exact root cause is unknown at this time, I suspect drop in voltage due to cable length / gauge. Replaced cable with one that came with the Duex5 and DuetWifi immediately booted and does so evertime now. Plus I no longer need USB connected to boot and serial over USB is working again.

So the longer ribbon cable was causing nearly every issue I was having. Not sure if it's just a cheap cable, got two in a pack, both exhibit the same behavior. Regardless I am back online and letting folks know in case they run into the same issue.

Dave, not sure if you have a warning on the Duex5 page about this, but you may want to add one. Use good ribbon cables… 🙂

That's great to hear. Thanks Dave.

There are no gcodes to send SPI signals. I'm not sure that it would be practical to define any, because SPI peripherals vary so much in what data they expect and what they return. Maybe it would be practical for simple output-only devices.

If you are not using thermocouple or pt100 interface boards then the easiest place to pick up the SPI signals is probably the header that the daughter boards plug into.

Cool, it's sold! 🙂

PanelDue with a 7" screen draws about 700mA from +5V. The Duet itself draws less than 200mA. So 3A should be plenty.

Excellent, thanks for the update!

Excellent, thanks for the update!

This has been implemented in DWC. Every time you edit your config the old one is moved to "config.bak".

Ok, I figured it out.

Marlin outputs the temps while M109 is heating up. Since I am using Octoprint to run my print jobs, it is timing out during the cool down because there is no output from the firmware until the temp is within a few degrees of the target, then M105 replies start coming back. Octoprint is assuming a timeout and dumping the connection, that leaves the last command received by the firmware the M109 and why none of the remaining gcode is run because Octoprint bailed.

I tried putting M109 and M140 into long running commands, but the default time for is still too short. I can bump the timeouts way up to avoid the issue, and will for a short term fix.

Is there any reason why the temp is not sent via the serial connection during M109?
I found the following discussion, but I don't see that anything came of it. I could send a PR for the change if desired. It would be very useful to see the temp during heat up via the serial connection.

http://forums.reprap.org/read.php?146,612559

All the hardware-PWM-capable output pins are assigned to heaters and fans. Currently you can't reassign the heater pins without recompiling the firmware, because the associated PIDs are liable to overwrite anything you write to them. I intend to introduce an M code that would let you specify now many heaters you have, thereby allowing the remaining heater pins to be used as GPIO pins.

The Duet WiFi expansion boards we are working on will also provide additional PWM channels.

Yes that should work. If the fan has a brushed motor, connect a flyback diode in parallel with it.

By default, each heater is controlled by the thermistor associated with that channel. You can change that using the X parameter in the M305 command for that heater.