Duet has stopped talking completely (moved from another thread)

I'm having problems with the web interface: (on 1.09e)
-At first the response to manual jogs would have erratic delays, sometimes up to a minute (or what felt like one)
-Also uploading a new config with motor currents turned all the way down to 100 (after trying 500, then 200, etc) did not seem to affect the motors moves.
-Then, after several successful config file uploads, uploading would fail.
-I have now powered down the PC and the printer, AND unplugged the LAN connector in case it was leaking power into the pcb. Then repower/boot it all.
-Now it won't even connect. Ping reponse is ok but it gives the message 'Destination host unreachable'
-Pronterface (connecting it after all of the above was performed) can't connect either. Window's does show it's COM port in Device Manager.
-I haven't touched the SD card during all of the above (except uploading through the web interface)

It almost sounds like the firmware is not running or corrupted, somehow. Didn't want to reflash it yet.
Ideas?

edit: PC and printer are connected through a local gigabit switch sitting on a larger home network.
edit: If not cached, the printer web interface does not appear at all if I close the browser then go back to the printer IP.
edit: PC can still browse rest of the network.

Did you have an upload of config.g fail? If so then the config.g file on the SD card may be corrupt or incomplete, in which case it won't be able to read the network settings at startup. Try moving the SD card to a PC, run chkdsk or equivalent on it, and see whether the config.g file looks OK.

There was a change to the network interrupt priority in version 1.09e, so as you seem to be getting persistent network errors, it might be worth trying 1.09d. You could also attach Pronterface to the USB port and see if it reports any network errors.

Edited 1 time(s). Last edit at 08/18/2015 12:12PM 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].

I will look at the SD card..what does the firmware do if the card is not read (other than lack of IP)? I ask because one of the last checks I did WAS try Pronterface (no connect)
Assuming the SD card is not the problem:
At this point do you think there is no reason not to reflash?
I hate to erase the problem and lose whatever useful troubleshooting info might be available in case I need it later.
BTW, I have a scope and was thinking it might be useful to prove something 'live' to see whether the MCU is in a full coma and not just paraplegic.

Pronterface expects the printer to return "OK" in response to commands, but the firmware doesn't do that until it gets the M555 P2 command (i.e. switch to Marlin emulation mode), which is normally read from config.g. So without the config.g file, Pronterface won't connect either. OTOH it's possibhle to use Arduino Serial Monitor to send commands and see the results (e.g. send M105 and get the temperatures back).

I think I'll change my fork to make Marlin emulation mode the default - I don't know why Reprappro didn't do this in the first place.

Edited 1 time(s). Last edit at 08/18/2015 04:42PM 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].

Ok, disk check found no problems on the SD card.
Arduino serial monitor could not see COM9 as presented in Device Manager.
bossac could not see COM9 either.
After using the erase button on the pcb I was able to get bossac to upload ok.
Then Arduino serial monitor worked, but M503 indicated the card was not read.
I put the card back into the PC and overwrote the entire card with my working contents from the PC, then put back in.
Reset then worked, contact with the browser is established. Motor current settings respond as expected. Yay!

question: what is that yellow/red flickering-around-500 Z-probe sensor display in the browser control? I'm sure that 500 reflects the setting in the config file, but that 'live' reading doesn't change when if I trigger the z-probe LED.

Thanks for the help. I just wish I knew what caused the problem. I will keep an eye on the SD card, and if this happens again, try with a different card. I am suspicious though of 'normal' activity that can knock out the MCU so easily..

Edited 1 time(s). Last edit at 08/18/2015 11:40PM by shadowphile.

well this thread is now off-topic

Z-probe readout will not change, despite a proper response all the way to pin 26 of the MCU.
The ADC on that pin appears to be working because I am getting a fluctuating readout around 500.
So it seems like the MCU is broken .
Please tell me there is hope because this board is expensive and took a long time to get here. And it is 0.6, bought it as a duex4 bundle from think3dprint3d.
(if necessary and feasible I would rewire to another ADC input and modify the firmware first, although I read that compilation can be difficult)
thanks

If you are using my IR sensor board then you have its output connected to the wrong pin on the Duet. The E0 connector is used for switch-type Z probes. See the wiring diagram at [miscsolutions.wordpress.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].

ack..sorry about that, thanks for the pointer.
(I don't care for the reprap site..I can never find anything!)

ok, probe is working ok now.

As for the probe calibration process, I notice what seems to be a missing note:

To calibrate the sensor for Z homing and bed probing, home X and Y, then position the head over the centre of the bed. 
With the nozzle at operating temperature, lower the head so that it is just touching the bed or just gripping a sheet of paper,
then send G92 Z0 to define that position as Z=0. 
Remove the paper and raise the head in small steps until the LED illuminates, and continue raising the head until it goes out again. 
Now lower the head in 0.05mm steps until the LED illiminates again. Read off the Z height and use that value in your G31 command in config.g.

When the height is set to 240 (in my case), then the probe can't be manually jogged down to the surface to measure the Z offset. So I set m666 h250, which goes below the bed a little.
But when I re-home then run G30 P0 X0 Y0 Z-99999, the head presses right down on the glass before the probe can do anything. So I then reset m666 to h240; THEN I can run the the G30 command with the expected behavior.
Does this make sense?

thanks

Quote
shadowphile
ok, probe is working ok now.

As for the probe calibration process, I notice what seems to be a missing note:

To calibrate the sensor for Z homing and bed probing, home X and Y, then position the head over the centre of the bed. 
With the nozzle at operating temperature, lower the head so that it is just touching the bed or just gripping a sheet of paper,
then send G92 Z0 to define that position as Z=0. 
Remove the paper and raise the head in small steps until the LED illuminates, and continue raising the head until it goes out again. 
Now lower the head in 0.05mm steps until the LED illiminates again. Read off the Z height and use that value in your G31 command in config.g.

When the height is set to 240 (in my case), then the probe can't be manually jogged down to the surface to measure the Z offset. So I set m666 h250, which goes below the bed a little.
But when I re-home then run G30 P0 X0 Y0 Z-99999, the head presses right down on the glass before the probe can do anything. So I then reset m666 to h240; THEN I can run the the G30 command with the expected behavior.
Does this make sense?

thanks

Yes, I can understand that. By default, my firmware fork doesn't let you go below Z=-0.5 on a delta, and the default bed probing dive height is 4mm. So you need to set the M665 H parameter to within -0.5/+4mm of the actual homed height before you use the probe. There are a couple of workarounds if you can't estimate the homed height that accurately:

1. Send M564 S0 to disable limits, allowing the head to go below -0.5mm. Then it doesn't matter if you set the homed height too small.

2. Send M558 H50 to increase the Z probe dive height to 50mm. Then it doesn't matter you set the homed height up to 50mm too large.

Edited 1 time(s). Last edit at 08/19/2015 10:04AM 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].

ok, I am adjusting for tilt now with the H parameter. I see a real-world usage headache though:
Unfortunately, I need a coat of PVA which causes unpredicable changes in the IR reflection. Meaning I have to scrape the bed clean before every auto-level. Cleaning off PVA is a difficult scraping job even wih a razor blade so I leave it on and touch up after every print. If I auto-level each day for the first print then I need to go through the scrape-off process every day. Am I in tune with reality here?
thanks

also, if I'm going to do 0.1 layers, .05 steps really aren't enough. How about adding a finer step resolution like 0.02 to the interface?

also, what are the units of the H parameter in G30? can I use fractions?
thanks

Quote
shadowphile
ok, I am adjusting for tilt now with the H parameter. I see a real-world usage headache though:
Unfortunately, I need a coat of PVA which causes unpredicable changes in the IR reflection. Meaning I have to scrape the bed clean before every auto-level. Cleaning off PVA is a difficult scraping job even wih a razor blade so I leave it on and touch up after every print. If I auto-level each day for the first print then I need to go through the scrape-off process every day. Am I in tune with reality here?
thanks

Last time I tried PVA was a while ago, and I don't think it made much difference to the trigger height. But I now use a very thin film of sugar solution on the glass, applied with a tissue. It gives me a reliable trigger height, and I can do many prints on it before I need to clean he bed and apply the film again. I also have 2 different brands of hairspray that don't affect trigger height, although I am aware that some other brands do.

---

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

Nevermind, I finally found the G-code interpretation in the code. (H parameter is a float so must be in mm not steps).
Right now I'm calibrating the tilts and I did it with no heat, with just the head at about 240 and then also with the bed heated to ~100 c.

DC42, have you studied how the IR pcb responds to temperature? The hot-end doesn't put out a lot but the IR board floating over a hot bed DOES expose it to a lot of temperature rise.
Some points offsets have no change at all between hot and cold (head only) and other points like .12mm, which would be impossible to trim out with the H code if I plan to use the bed both hot and cold.
I think some of this is mechanical limitations of my build, ie the bed mount is on the insulating cork, not the the glass or heat plate.
Anyway, still interested in the thermal characteristics of the IR board.
thanks

Even with the g release I installed, I keep getting an repeated AJAX error that disconnects me (umh..once or twice an hour, maybe more). I don't have the actual message because I copy and pasted but the copy didn't take.