In a previous life, I was the admin of a large computer network. One of the best features of the Cisco gear we used was the command "show tech-support". It spits out a huge text file with the entire configuration of the device, along with a number of diagnostic command outputs, error and operation logs, component temperatures, version info, etc.
The file could either be used in-place for diagnostics or sent to Cisco tech support for further analysis, sidestepping a lot of back-and-forth with the support people.
It occurred to me that it would not be that hard to achieve something similar, either implemented in firmware or else done in DWC. That file, uploaded to the forum (perhaps via an automated mechanism direct from DWC?) would provide a huge amount of troubleshooting data very easily.
Even better would be a way to unpack that data into a visualiser/validator tool that showed common issues, potential conflicts, firmware upgrade 'gotchas', etc. Again, this is something we had with Cisco where complex configurations led to difficult-to-spot and subtle issues. I appreciate that this is not trivial to implement but it wouldn't have to happen all at once and, once done, might actually cut down on the time spent troubleshooting, especially with 'new user'-type issues.
@doctrucker Indeed, my idea is that a really cheap machine is not really worth considering. But building a decent machine as cheap as possible, taking advantage of all possible offers/bargains, without cutting too many corners, is a completely different idea!
I bought good Lapp Kabel multi-core, screened cables from Farnell - 0.5sqmm/core (that is usually around 5A continuous current). The code 1891252 is for 4 cores cable, around 1.7EUR/m all included and 2499550 for 2 cores cable, around 0.85EUR/m. For my WorkBee I actually needed in the end cables costing about 15-20EUR in the end (I have used too much 2 cores cable!). If that is relatively expensive when considering the cost of the machine, then that is a really cheap machine. Again, when I mention "cost", I consider the actual value of the items used to build the machine - if you can get for free items values over 500EUR, that is a machine built cheaply and not a cheap machine!
After one year of using the WorkBee, mostly for milling Aluminum and POM (Delrin), it needed new V-Slot wheels on the Y-axis. That is 28 OpenBuilds polycarbonate V-wheels, including some accessories - all values North of 200EUR. With 100USD I bought a set of SBR12 linear guides, thrown in some elbow grease and some clever machining (with the WorkBee already crippled!) and the end results is more rigid than the original. While being cheaper, again, it was not done "on the cheap"...
@rivam said in Sparkcube v1.1 XL MABL, FTS and PT100 controlled by a Duet Wifi?:
Concerning the feed sensors: Will it be possible to use them to calibrate the extrusion speed? e.g. running an extrusion and comparing the intented steps/distances with the measurements so you can finetune the maximum extrusion speed?
Using the laser filament monitor: yes, because it reports absolute distances.
Using the magnetic filament monitor: not sure. The filament rotates a hobbed shaft, so the calibration will depend on how accurately that shaft is machined, and possibly on how soft the filament is. So you might need to do an initial calibration at low speeds, then the filament monitor could calibrate the nonlinear extrusion coefficients needed for high speed extrusion.
I only asked because the CTE varies slightly depending on the alloy, that said, it doesn't vary enough to make a huge difference.
The granite plate plate solution is interesting, but how did you get around it's poor conductivity?
@randomfactoid said in Mid Air Prints unless I Restart:
@dc42 thanks to your suggestion about the simple gcode, I think I found the problem.
Apparently if you have G10 in your pause.g (or, I suppose anywhere in your Gcode) and have Z hop defined in M207, after cancelling the print (or, I'd guess, finishing it without unretracting), after starting a new print, z=0 becomes the value of the Z hop height in M207, because it zhops, the print gets cancelled or finishes and never actually zhops down to previous height.
I tested this by uncommenting G10 from my pause.g and the problem disappeared. I also tried setting M207 Z(random number) and after starting a new print, Z=0 is at a height of (random number) and actually you can jog the nozzle into negative numbers after stopping the print...and it goes right to the negative height of M207 Z value.
This seems like a bug in the firmware as Zhop height doesn't get cancelled after the print finishes without unretracting.
Thanks for the report. I've added this to the development list for the next 2.03beta release. Meanwhile you can work around this issue by putting G11 commands in appropriate places, for example in cancel.g and stop.g. Perhaps also in your slicer start GCode and in homeall.g. A G11 command will be ignored unless there is a G10 command that has not already been undone using G11.
So I had a chance to take a look at your config on a proper screen now, and I still think there are some things that could definitely be causing you issues.
M350 X64 Y64 E256:256 I0 ; high enough microstepping to cause hiccups
M350 Z4 ; Low microstepping on z axis
M566 Z750 ; high jerk for z axis
M203 Z1000 ; high max speed for z axis
M906 Z2600 ; max motor current into a tiny pancake motor
Combined with all of your quoted commanded Z moves would be requesting the full max z speed.
I think you might have best results with x16 microsteps across the board with interpolation to 256. Possibly higher for the extruder if it results in less than 400 steps per mm. I wouldn't be surprised if your microstepping settings are high enough to trigger hiccups and possibly missed steps.
Reduce the max Z speed to 300mm/min.
Reduce Z jerk to 50mm/min
It's not clear to me if you are using the Za and Zb motor connectors, or if you're using independent drivers for your Z axis. either way you may want to revisit your current settings to see what the motors are actually receiving, as your M906 Z2600 would seem very high at first glance.
You can also make a copy of everything on the card by putting it in a PC or Mac and copying the files.
The firmware itself once updated is actually on the board, not the SD card. The bin files on the SD card are just left over as backups.
That looks slightly amiss to me. As @Phaedrux stated, what you are seeing is the pressure advance coefficient for both drives, even though specified "DO". I just checked on my machine in 3 extruder configuration and in response to M572 D0, I get "Extruder pressure advance: 0.400, 0.400, 0.400" and I get the same response regardless of whether I use simply M572 or M572 Dn (where n can be 0 to 2) so it seems that M572 on it's own reports the pressure advance for all drives and ignores the "D" parameter.
Edit - it's just how pressure advance is reported. You can still change the setting for any individual drive and it will work. In the example above, I entered M572 D0 S0.5. Then entering simply M572 reports back 0.500, 0.400, 0.400. So everything works as it should.
In this case, no matter what, static on the Duet or not, the Duet MAC has to be on the switch port at all times. If not, the Switch will not know where/what port to send the packets. And your PC keeps an ARP table with every IP address and MAC of local devices, or MAC of Gateway for all devices that need to be reach via gateway/router. I maybe speaking a foreign language now.... But if the MAC isn't on the switch (and the switch is working properly), something maybe wrong with the NIC on the Duet. Funny thing is, it appears to stop working every 20 to 25 days and maybe more often during extended time prints over/around 30 hours. (I also do not shut my 3d Printer off)