Posts made by tj

Have you created a ticket at the octoprint github?

No, and I don’t think that would be appropriate. I have been using this Duet/OctoPi configuration since my first Duet Wifi installation (v1.17) and it has never had the slightest problem until now. This does not point me to the conclusion that there is something wrong with OctoPrint that needs to be corrected. It does not point me to any conclusion. My working knowledge of RRF and OctoPrint is good enough to get by, but no better. That is why I said I would leave it to others.

Thomas

Octoprint says it is sending "N0 M110 N0*125" but RRF is behaving as though it has received "WiFi module is cN0 M110 N0*125". It's as though the message "WiFi module is connected to access point..." has been sent by RRF but either RRF or Octoprint or the USB CDC port driver on the PC has echoed part of it back to the input. Octoprint then sends the M112 emergency stop command.

I looks like this was the problem. All three of my printers have an OctoPi board which powers on at the same time as the Duet WiFi board. I use a DC to DC converter to take Duet VIN and make the power for the Pi board.

I just tested two of the printers by changing the Pi power source to a separate switch and now with the Pi boards left unpowered the Duet boards will cold boot like they should. I don't know yet how long the delay needs to be before the Pi power can be applied.

None of this was changed when I migrated to v3x firmware, it all worked fine on v2.05.

Also, now if I power up the Pi with the Duet power source off, the Duet will turn on through the USB power (from the Pi) and I do see the cold boot fault again.

So that't it! Now it is just a question of whether Octoprint or RR3 need to change anything and I will leave that question to others.

Thanks all,
Thomas

OctoPi_console.txt

For those who can understand the output result of an M122 command (not me) this one might be more helpful than the one I posted earlier.

The previous console.txt came from DWC after DWC required me to "RESET MACHINE". I was able to use OctoPi to issue an M122 without needing to do a reset first.

Hopefully this will let you see more about what happened between "power up" and the "machine reset".

Thomas

To be precise I was never on 2.05.1, I started from 2.05 and I have not tried to revert. I wanted to post on the forum before I did much else to first see if this was a known or obvious problem. I guess no such luck there.

Remember that this only happens on a cold (power on) reset and it happens on every POR. I have (so far) never seen it happen on a reset where the power is already on. This makes it fairly benign to live with.

My own hunch is that it has something to do with the PT100 RTD adapter. All my Duet printers have this and most Duet installations probably do not. It appears to be some kind of false high read on heater1 that triggers this event.

If no one else has a better idea, my plan of attack will be to start commenting out lines in the config.g file to see if we can find a line that is related this problem.

Thomas

config.g config-override.g console.txt

Here are the files from one of the printers. I ran the M122 as soon as control returned to DWC after restart.

Thomas

I just update three printers from firmware 2.05 to 3.1.1 and all three are having the same issue during a cold boot.

1. The boot looks normal on the PanelDue display and heater temps read normal for the first 25 second, then I get the message "Emergency Stop! reset the controller to continue." and when that message disappears the heater1 temperature display reads a normal temp but in yellow.
2. On the DWC side, it is trying to connect and giving me the message "Please stand by..." with a "RESET MACHINE" button as my only option.
3. The warm reset is always normal and the Temperature Chart in DWC show an off the scale, single line, spike reading on heater1 has occured after the cold boot, which is obviously what triggered the emergency stop.
4. This happens every time, on all three printers during a cold boot, but never happens any other time.
5. All three printers are using a PT100 probe with the Duet PT100 board for the heater1 hotend.
6. I can post the config.g files if needed but they were all created by the "reprap configurator" web site with only minor tweaks made to a few parameters.
7. Once I do a warm reset after the cold boot issue, the printers all work just fine on f/w 3.1.1

Thomas

When the red light goes off the Precision Piezo digital signal has triggered. I sounds like the duet is not seeing the signal correctly. I would recommend:

1. use the digital signal
2. use the z-probe connector
3. M558 P8 H3 I1 F300

You will need to play with the sensitivity to prevent premature triggering during the probe dive.

I recently upgraded a delta printer/duet wifi to use the PT100 sensor for the hotend. This allows me to swap effector/extruder assemblies with another similarly configured delta printer. I am seeing a lot of erratic temperature readings on the newly configured system which I do not see on the other printer and I see the problem with all of the effector/extruder assemblies.

This does not happen every time I print but the graph shows a back to back occurrence where I killed the print and started it over. It always seems to start after the initial heat up is completed and the problem clears by the time the temperature drops for the second layer.

The stepper and PT100 wires in the umbilicals are separately shielded. Both Duet boards are running v2.02 but the problem system is 1.0 hardware and the other is a 1.04.

I guess the next step is to swap the PT100 boards and see if the problem moves to the other system. Has anyone else seen this before?

You did not state if this is 12v or 24v. I use the same E3D motor with a Titan on 24v at 1000ma with no issues. Not an expert on this but I seem to recall that the 0.9 degree motors do not do as well on 12v.

OK, I found it myself. The files deployprobe.g and retractprobe.g needed to be removed from the /sys directory. Now it works like it did before.

Tom Johnson

I just did a big jump firmware upgrade from 1.17 to 2.02 which overall went smoothly. The issue is that Auto Delta Calibration is now behaving strangely. Now between each calibration point the head goes through a strange and lengthy movement sequence.

Any ideas what I missed here?

Tom Johnson

Could be the same problem I had:

https://www.duet3d.com/forum/thread.php?pid=8405#p8405

Is your 2.4ghz channel set to "AUTO"?

Just to clarify two things…

1. I chased this problem over a period of about five days, with many power cycles on both the network hardware and the DuetWiFi board. The problem was persistent and repeatable although some days seemed worse than others.

2. I did not go through a list of channels to find one that worked. Channel 6 was the first one that I tried, and it worked.

I have been setting up a new (Ultibots D300VS) printer with a DuetWiFi board and I have had a very difficult time with the WiFi connection to my router. Even though the network name and password were set correctly, I usually could not get the Duet board to connect (but sometimes it would). It would just keep coming up in "access point" mode and my network would rarely appear in the list of available networks (but sometimes it would). All of my neighbors networks always showed up just fine.

My wifi/router is a Linksys/Cisco E4200 dual band which has been running without issues for several years. After some poking around in the settings I found one change that made a huge difference. My 2.4ghz band had the channel set to "AUTO" and since I changed it to use "channel 6", I have gotten a connection first try every time. I don't know enough about wifi networks to explain why this fixed the problem but I wanted to pass this information on.