Estlcam uses the “System.IO.Ports.Serialport” namespace of the .NET 4.8 Framework for serial communication and handles the programming itself (which is very easy and straightforward - absolutely no black magic involved).
It surprises me that this part seems to be the roadblock.
The whole application relies on .NET 4.8 and such a basic and old school core functionality like serial port communication feels strange to be missing. If Estlcam crashes the functions may really just not be implemented. If it were a permissions issue I’d expect “Port.Open()” to just fail and return which Estlcam would catch a few moments later by verifying “Port.IsOpen” and seeing that it is still closed.
Also no Win32 or other external function calls around this part of the code - it is all within the usual .NET Framework functionality. The only potential issue I’d have imagined would be after sucessufully connecting to the programmed controller where a “kernel32.SetThreadExecutionState” call tries to elevate Estlcams process priority. Something a strict system like Linux may refuse without admin privileges - but this function is not called during programming and it also wouldn’t be too much of an issue if the priority elevation is just refused and the function returns otherwise normally - it would only add some lag if the computer is doing a lot of other things at the same time.
If someone is able to pinpoint the exact function where everything hangs up I might be able to find a workaround.
Thank you, Christian. This all sounds pretty much like Greek to me… hopefully some more knowledgeable folks will speak up and offer ideas. And someone who uses Estlcam regularly will also hopefully try this and verify that all the CAM functionality is as good as hoped; i.e. I haven’t used Estlcam more than a couple of times… and years ago.
Is this with an arduino that has already been programmed outside of bottles? If only the programming is the problem, then that might be useful info for Christian.
It’s really hard to guess. Bottles is remapping all of those calls to other functionality. Most of it has been mapped correctly, but obviously not everything.
Would Estlcam handle it if that function threw an exception instead of just quietly failing? Is there any way for David to get a log or trace of Estlcam while it’s crashing?
It’s just an old original UNO that I pulled out of the junkbox. It’s been programmed numerous times but not through Bottles until these tests. It had “blink” already on it when I picked it to play with. Please ignore the dog hair…
I’m also trying to get ESTLCAM working under bottles, unfortunately without a dog on my lap.
I managed to find the following: com35 is linked to /dev/ttyUSB0, that’s where my estlcam controller is connected to. When I configure the software to use this port estlcam crashes with the following message:
Exception: the method or operation is not implemented
Source: estlcam12
I get the same error message when I choose another comport (that is linked to another device IE com1 is linked to /dev/ttyS0)
You can see what port is linked to which device in /home/USERNAME/.var/app/com.usebottles.bottles/data/bottles/bottles/Estlcam/dosdevices/
I did the same yesterday. I figured out that the crash is related to mono. I got a wine prefix working with dotnet 4 & 4.8 instead of mono.
When setting up a comport to /dev/ttyUSB0 estlcam won’t crash anymore when I try to flash the klemmadapter controller.
I tried to somehow debug what is happening, but did not find anything useful yet.
@christian-knuell is there a way to get some verbose output from estlcam to see what is happening there?
Also I tried to recreate that with bottles. When I set up dotnet instead of mono, the program wouldn’t start anymore. I have no clue why it works with “plain” wine and not with bottles.
Another observation: in “plain wine” the font in estlcam is the correct one, in bottles it is replaced with an alternative. Both environments have the same fonts installed.
Running EstlCAM on MacOS via WINE gives me a problem where the text/font in the tooltips is enormous and makes a lot of the tooltips unreadable. It’s not a Mac resolution problem because the tooltips are just fine running it in Parallels instead of WINE.
Just adding it to the convo as a data point in case it is helpful
