We still need shared library?

[drschlaumeier]

donovan6k, I suggest to make a voting at the m3d forums to check if someone still using shared lib. I personally did not use anymore since last year. It may release some maintanance work for you?

[donovan6000]

I tried to do this once before when I first implemented on-the-fly pre-processing, but I ended up bringing back the shared libraries a couple of days after I remove them.

The 'Pre-process on the fly' and 'Use shared libraries' settings are connected in some ways. So there's a single function called 'preprocess'. It's capable of pre-processing an entire file when on-the-fly pre-processing is disabled, and it's capable of pre-processing a single command when on-the-fly pre-processing is enabled. This function has two separate implementations, one is in Python and the other is in C++. When shared libraries are enabled the C++ 'preprocess' function is used, and when shared libraries are disabled the Python 'preprocess' function is used.

Now you wont notice much if any speed differences when using on-the-fly pre-processing since the C++ and Python 'preprocess' functions have plenty of time to process commands between sending commands since the baudrate with the printer is only 115200. But you will notice a huge speed difference if when not using on-the-fly pre-processing since it has to process the entire file at once, but seriously who's not using on-the-fly pre-processing nowadays.

The real problem with me removing the shared libraries is that there's also separate Python and C++ implementations of the 'collect print information' function that gets called before printing when using on-the-fly pre-processing or before processing a file when not using on-the-fly pre-processing. When not using shared libraries, the Python implementation gets used and on my laptop is can take up to 2 minutes to collect the print information of a large file as opposed to the C++ implementation which takes at most 5 seconds.

If something takes 2 minutes to do on my laptop, then I could easily imagine it taking 20 minutes to do on a Raspberry Pi. So the 'collect print information' function is the reason I brought back the shared libraries, and it's the reason that you should be using the shared libraries if your using a Raspberry Pi.

[drschlaumeier]

Woahh, very detailed explanation. However, Since December I stopped using shared library in Rpi2. Yes, you are right the "collect print information" takes some time but never 20min. something like 1-5min (some Mb gcode file). The advantage of gcode preview in octoprint is higher than speed during "collect print information". BTW: It would be nice to have som progress bar in % when collect print information is running.

Anyhow, what you think about using shared library only for collecting print information and when printing switching to python lib ... or did I miss something thats already implemented as such ?

[donovan6000]

We could use the shared libraries for just collecting print information, and that'd be a good solution. If M3D ever does a big change to the pre-processors then I'll think about doing that. Since the shared libraries are already setup and working there's not much point to reduce them to just being the collecting print information right now.

It's difficult to get synchronous communication working between the shared library and M3D Fio which is what's necessary to display progress when collecting print information. I tried establishing some way to have them communicate back when I first created the shared libraries, but everything I found about it either didn't work or was platform dependent.