ghbarbehenn

The suggestion has been made to delete the log files in %appdata%\cura. I have attached the log files from the successful execution of v5.3.1 (please note that stdout.log is empty, and so this app refused to attach it?). I then deleted them, and installed v5.7.0, which, not unexpectedly wouldn't start. However, it *also did NOT create* any new log files while attempting to start. So, deleting the log files in %appdata%\cura did not fix the problem, and in fact v5.7.0 doesn't even get as far as creating a log file. Perhaps the "debugging" was left on, and the offending call is to a logger? stderr v5.3.1.log

Installing up to version 5.3.1 works fine. Including installing it to a custom location, in my case the D drive. I'm installing it onto an Alfawise Z83 tiny PC, that lives in the garage with the 3D printer. I access it by remote desktop. The PC only has 32GB of internal storage, barely enough for Windows 10 Home (WinPE version), since Windows is a disk hog, so I have installed a 128GB SSD via an internal USB port, HDD D:\, and put all my applications on D:. If you try to install v5.4 and up you get the attached error message: Error message from 5.4 and above.pdf This message results from a call to a non-existent handle in the QTWidgets DLL, distributed with the version. If version 5.3.1 is installed, it can be started correctly. If v>5.4.0 is installed *on top of* v5.3.1 (same directory), version 5.3.1 won't start, and throws the same error message. Installing on top of another installation isn't kosher, but it is an interesting experiment showing that the QTwidgets DLL is the problem. It should be noted that I had v5.7.0 running on this PC. This PC has been used this way since v4.5, or so, and I just added the new versions as they came out. When I added the 128GB SSD, I damaged the OS image, and had to replace it. Since then I have been unable to reproduce the functioning installation. Nevertheless, v5.3.1 installs and runs *every time*, v>5.4.0 never runs after installation. My installation of Windows 10 Home is completely up to date, so this isn't a Windows staleness issue (polemics aside). I don't have Python installed on this machine, but the error is the call to a non-existent handle in the QTwidgets DLL, not Python. There is clearly a problem with a call to a non-existent handle in the QTwidgets DLL distributed with versions >5.4.0.

It isn't just the M82 that is strange. Cura 4.10 is also zeroing the extruder twice, and doing a 6.5mm retraction before printing: G92 E0 G92 E0 G1 F1500 E-6.5 As the M82 only needs to appear before the start of print, it shouldn't be located before the user start GCode, it should be after. But I can live with that, it is more academic than practical, assuming it isn't the 'thin edge of the wedge'. That is Cura won't eventually insert a bunch of lines before user start gcode. However, I prime my extruder by printing a 100mm long stripe from 0, 0 to 0, 100. The double extruder 0 smacks of either a bug or some sort of patch for Ultimaker 3D printers? The retraction causes the first layer to start extruding some 10s of mm after start of the first layer print. Why is it there? Is it controllable in the configuration of Cura?