ghbarbehenn

Thank you for your thoughts jaysenodell, but I do understand the system. My comments about the rudimentary nature of Octoprint's slicing were a reflection of the authoress' own comments. Although Slic3R, arc welder, and other plugins are available to slice in Octoprint, slicing in Octoprint is deprecated. I have loaded a variety of plug-ins and learning to play with them. I have also now loaded the Octoprint interface plug-in, in Cura 5.7.0, linked to my 3D printer and printed a job, via this tool chain. And I must say that worked very, very well, indeed. The Octoprint interface connects to the interface service, and invokes the web page automagically when the a print job is sent to the printer installed, in Cura 5.7.0, as the IP device.

Thank you DivingDuck, I do have it up and running on the Z83 Tiny PC. Octoprint seems very functional, and well thought out, but it could certainly use an overview description. It wraps a web site around a 3D printer connected locally to the PC hosting the web site. In theory this web site could be accessed from anywhere, but security issues make it impractical to do so from anywhere but your intranet. The interface is still file based, so it would be highly useful for Cura to talk directly to the service. And perhaps even embed the web page into Cura, since Octoprint can only do rudimentary slicing. I was able to point Octoprint to a local NAS for its various working folders. But in any event, I have it up and running and have printed a small project via Octoprint. The number and diversity of the plug-ins is significant, so the learning curve is not instantaneous. But that is my limitation, not the tool's.

Thank you, DivingDuck, I will look into the server on my tiny PC. Raspberry Pi is back to Linux, and not useful to me. So, please allow me to restate what you said to improve my understanding. The tiny PC copy of Octoprint connects to the LAN, and the 3D printer via USB. So, that would also mean that I would have Octoprint running on my laptop (where the slicer is). And that the laptop copy of Octoprint, would then send the gcode file to tiny PC copy of Octoprint, to feed it to the printer over USB? If I understand Octoprint, the copy on the laptop could display progress (and apparently camera video as well), of the 3D printer relayed by the tiny PC copy? If this is the case, it would meet all my needs.

I have Octoprint, as others have suggested it as well. Near as I can tell it can only communicate with printers that have an IP connection? This solution appeals to me for a variety of reasons, including the fact that the processor on the Z83 wasn't born to slice, so to speak. But, I couldn't figure out how to have Octoprint talk to a USB printer on the Z83. If this is possible, perhaps you could suggest where to start on figuring out how to do that? I have a complete wired LAN, in my house, so this would work well if I can figure out how to use Octoprint with a USB connection.

I apologize for my stridency, it was not intended to "go after" anyone. But correcting me without understanding the platform in question was 'going after' me. Especially since the my original comment on Iron Python wasn't germane to the problem, it was intended to forestall any questions about my ineptitude in Python coding. Also, telling me that logging was on by default, when my original post said that no log files were created, meant that the original post wasn't read, completely, before commenting. And lastly, I have reported all these issues, and more, on Github. I document them, and a few days later they are closed, because "further or requested information wasn't received". This has happened several times, so I despair of that path for a remedy. I have never had to do anything special, other than install the app for "all users", to make it it work with remote desktop. So as far as I know neither explicit support nor recommendation is required from Cura to make it compatible with remote desktop. And in fact, it works fine with remote desktop, as long as the remote desktop link isn't disturbed *at all*. I do note that the installer doesn't ask if it should be installed for the current or all users, and it should, or default to all users. This is a default option presented by the Windows installer, YMMV for other installers. By the bye, I also reported that to Github, and it was "closed because further information wasn't provided". I also reported that USB connection to the printer isn't consistent. I was told USB connection wasn't supported, and the issue closed. In Windows, Device cataloging, departure and arrival via the GUID is robust, so the above response is opaque. For me remote desktop access is driven by a physical disability and access to the 3D printer. It really isn't an option for me not to use remote desktop, hence the reason I'm so eager to get it working on the Z83. Again.

Well, first of all to *completely* clear things up Iron Python is *NOT* an interpreter, it uses the JIT compiler system common to all Visual Studio languages. Consequently, it is 10 to 100 times faster, and can access the entire dotNET ecosystem. In fact, Iron Python, C++, etc. (and yes even Visual BASIC) files can be mixed and matched in a Visual Studio project, because in the end it compiles them all to a common intermediate language that gets fed to the JIT compiler at run time. Second, how does the VMM react to insufficient physical or virtual (page file) memory? By throwing a system error, not "can't access a handle in a DLL". OK, so windows VMM isn't as effective as the YUKS (Linux and the rest of the band) platforms. So, it will either throw a system error, e.g. "out of memory", or crash. The "can't access a handle in a dll is clearly an applications level error", not a system error. I'm not a codee, I'm an electrical engineer and my experience with the windows VMM is from pivoting multi-gigabyte matrices in SPICE. I have generated many "out of memory" errors, particularly in WinXP as it can only have (nearly) 4GB of physical memory. This is doubly true when you allow Windows to manage virtual memory, as I do, because it will increase virtual memory as needed. Limited by available disk space, of course. And when it works correctly. The "can't access a handle in a DLL", message is not coming from the memory manager. The structure of the DLL is to have a table of calls mapping the called routine name to an offset in memory of the called routine. It is, essentially indirect. If the contents of the table contains an incorrect offset, you will get a page fault. The "can't access a handle in a DLL", is coming from the indirect lookup code, saying it can't find the requested routine in the lookup table, not that it couldn't find it in memory. Also, again, the Windows memory manager isn't as shiny as the YUKS one, so accessing forbidden memory, will generate a page fault, or send Windows into the weeds, not a courteous "I can't find that, please try again". Nevertheless, the missing handle exception returned by the Qt6Widget lookup should propagate back to the calling routine, allowing it to be captured and documented... Third, as I've already documented when Cura > 5.4.0 starts and crashes, it does not create either a version folder or either log file in %appdata%\Cura. If it did, I would have already appended it like a I did for 5.3.1. Any log file at all would help, as I have no idea where the problem is occurring, although it appears to be in the painfully slow interpreted loading of all the different printer profiles. As an aside, why aren't these loaded as needed, life is short enough, it takes forever, even on my I7 laptop? It is worth noting that after invocation the spinner comes up for a few seconds, then goes away, and it is 10 or 15 seconds before the error appears. So, this fault isn't occurring at init, yet *there are no log files generated* (or application version folder in %appdata%\Cura), this is what is baffling me. The missing handle error is coming from Qt6Widgets.dll, which for some reason is in two places in the application directory, instead of the GAC, where it belongs. Cura 5.3.1 uses version 6.2.4.0, Cura 5.7.0 uses version 6.6.0.0. I would of thought that this DLL contains the "controls" used in the UI, which doesn't come up until after the printer profiles are loaded? I'm wrong about Python, as you say, but without a log file of any kind, what choice do I have to troubleshoot but change things until I get a response? So, I repeat is there a command line switch to enable logging, 'cuz *nothing* is created for versions > 5.4.0, full stop. I could attach a debugger, but generally the messages to the debugger are generated in the same exception handler that logs them, so... Finally, I installed Cura 5.7.0 on the Z83, and before starting it copied the entire application (application and %appdata%\Cura folders) from my laptop, also running Win 10 Home 64b, and where it runs successfully, to the Z83. The results where exactly the same. So, there is either a difference between the WinPE version of Win10 Home 64b running on the Z83 and the mundane Win10 Home 64b running on my laptop, or something, external to the Cura installation is missing from the Z83. Perhaps I should dismount from Rocinante, but I very much doubt this is a memory problem, which wouldn't prevent logging until lights out. Also, Cura is installed for the *current* user, not all users. Consequently, if started by a remote desktop session, it will stop if the remote desktop session is lost even for a second. "All users" is a built in choice in the windows installer, and presented by default, and it should be up to the user to decide which to use. And if not, it should be "all users", allowing disconnect from the remote desktop without affecting Cura.

Installed python-3.12.0-amd64.exe, from the Python software foundation, and the error message *changes* to: So, I'm off to find the wiz...uh QTcore. It appears that Cura >5.4.0 requires Python 3.x, but the installer doesn't install it...

As I said, Cura 5.7.0 ran on this system, I have several printouts that were done by this. In any event, Virtual Memory only slows things down and memory management problems would crash the OS, not throw an "unhandled exception". AND certainly not an unhandled exception because a DLL handle can't be found. Many times, while chasing an exception, I wished the explanation were so simple, but it is not, 🙂, even if Windows memory management isn't stellar. Search for problems with Cura 5.x, the search will turn up many people reporting successful install followed by a failed startup. Also again, why is the exception "unhandled" (and unlogged)? Does Cura have a command line switch to enable logging? This is not something that can be troubleshot by opinion, it needs to be troubleshot by identifying the cause of the exception. Also, there is a new folder, associated with Python, starting in version 5.4--Pythonwin. This folder contains a dll (mfc140u.dll v14.0.24234.1) and a python file (win32ui.cp310-win_amd64.pyd), are these the source of the problem (by the bye, all DLLs should be in the GAC, not the application folders)? Don't know, because I would be guessing. But, I do know that 5.3.1 installs and runs every time, and >5.4 installs but don't run, and I know that 5.3.1 doesn't have a Pythonwin directory and >5.4 do. Also when I run Python 5.7.0 on my laptop, it uses 590MB, with python consuming another 26MB. I may consume more at startup, but the page files alone, on my Z83 are about 3GB. Even windows can manage this, or at least should. If you're willing to wait. If the exception can be tracked to a misbehaviour of Windows Memory Management, then alea jacta est, but otherwise we are *guessing*. I don't code in Python, and if I did it would be in Iron Python, so it is beyond my skill set to use the Github source. Does someone have an instrumented flavor of Cura >5.4.0, that would log this exception?

I installed Cura versions 5.7.0 and 5.3.1, each in their own directories, and copied the contents of all directories starting with "py" *in 5.3.1 to 5.7.0*. I noticed that the 5.7.0 has a "Pythonwin" directory, and 5.3.1 does *not*. Also, doing this changed the startup behaviour, now the start up message is: Which, while not Joy, is a the ONLY change, anything I've done, that has produced a change from: I think that there is a registry entry or OS extension that is missing? This PC had the Arduino environment and several USB instrument applications installed, previously. Sadly, there were also several things installed that were removed (because the &*%&*% OS consumes the whole SDD), and I don't remember what (I've had it since 2016). Consequently, randomly installing things to fix this doesn't seem practical.

Yes, please find below: Z83 Mini PC full specs CPU: Intel® Atom™ x5-Z8300 Processor(2M Cache, up to 1.84 GHz) GPU: Intel® HD Graphics (200 MHz base, 500Mhz max) RAM: 2GB DDR3 ROM: 32GB eMMC LAN: 10/100/1000 WiFi: 2.4G + 5.8G USB: 1 x USB 3.0, 2 x USB 2.0 Audio/Video: HDMI, Headphone Jack, SD card (up to 128 GB) Other: Bluetooth 4.0 OS: Windows 10 I'm running Windows 10 Home 64b with a Thinstuff Thinclient for remote desktop. As I said the box has run Cura 5.7.0 before, since it came out actually. I'm only reinstalling now because I added a 128GB SDD, so that Windows can hog the entire C:\ drive, and damaged the OS image. Since I have page files on both, now I have approximately (I guess that with no PDFs, you also can't use ALT-247 for the approximation symbol) 12GB free on the C:\ drive. Please note that I am very (as in very unfortunately) familiar with the exception due to a non-existent call in a dll, albeit in .NET. The "unhandled" bit bothers me tho'. No log file is produced when this happens, and I don't know how it would be generated in python. But, in .NET, there is, or should be, an exception handler in each method. Then, when the exception is encountered, it can be logged, and the application can do something else besides crashing and burning. Since I don't see a log file (maybe I"m looking in the wrong place? I'm looking in %appdata%. 'cuz the OS won't let you programmatically write to the application directory) I don't think the exception is being handled. New experiments. As I said Cura 5.7.0 used to run on this machine, before I damaged the OS image, and had to re-install. I removed Cura 5.7.0, burnished the OS (cleaned out all the caches, temp files, restarted, etc.), reinstalled Cura 5.7.0, as administrator, using the complete option, no custom paths. Before starting I recovered the Cura 5.7.0 directory image from backup on my NAS, and overwrote the Cura 5.7.0 install directory. I tried starting Cura, with the same results. Looking in %appdata%, I saw that the last folder I had was 5.3, so I copied the rest of the contents of %appdata%\Cura from my backup on NAS. I then tried to restart Cura, with the same results. Are some particular OS extensions, like the .NET libraries, C compilers, etc, required for proper execution? At this point I have a complete image of the Cura and %appdata% Cura directories from backup on my NAS. But, I still have no joy, so this suggests to me that it is a registry or missing OS extension problem?

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?