When using the new version of Estlcam, the line output screen has been changed a lot and has some improvements, however parts of it are almost impossible to read on my computer screen such as the line number, the tool being used and tool change information. The text needs to be bigger and much darker, it is currently almost transparent.
I just had a crash and needed to note the line number, but was unable to read what the line number are, they were too light in colour.
On another subject, I created a CNC file in version 12 and tried cutting it using version 12 and had to try several times as I kept getting USB errors or the program freezing. I assumed that it was my control hardware, but as I have had not many problems previously with version 11, I tired cutting the same file with version 11 and it went ahead and completed without any problems.
EstlCam 12 Text seemed unexpectedly small to me as well. Recently stumbled onto Control scale setting which helped to fix. Find in Settings menu > Basic Settings menu item…
what hardware are you using?
And can you please send me the settings and cnc program file that causes the USB error crashes?
Maybe I got a communication protocol issue with one of the firmware variants.
I have taken a screen shot on my desktop computer, the notebook is a lot smaller and impossible to read. Taken two shots, one with the scaling at 1.0x and the next one at 1.08x, if I go any bigger the tool list covers more than the screen.
There doesn’t seem to be much difference between the two.
I am using Windows 10, a control board that uses an Arduino Nano wired to your specs in the software.
The last program file that caused errors but worked OK with version 11 front.nc (33.7 KB)
Not sure which files you need so I have zipped up all I can find. V12.zip (32.4 KB)
I have stripped the machine down now and am rebuilding with a new control box, waiting on a couple of parts to arrive so I can finish the build.
I’m currently in lap 3 of running your CNC program - so far without any issues.
I’m testing with an Arduino Nano and exactly the same settings you’re using.
Is there any specific action triggering the issue - or making it more likely to appear?
Or is it just randomly during program run or jogging the machine?
I’ve also fooled around a bit, trying to provoke something like enabling outputs during program run, changing the feed override, starting and resuming the program and so on - but no issues so far. The software side seems to be OK.
It may have been just a coincidence that the USB issues happened while testing version 12.
Do you use the most recent update?
Current version is 12.037 - but as long as it is not much older it shoudn’t matter much as there have been no firmware related changes recently.
Thanks for the advise Mike,
I already have ferrites on the cable and in other places also. Not had too many problems while running version 11, occasionally I would get a USB error, but most likely that was caused through knocking the cable connection while moving stuff around the work area…
I didn’t have limits setup on my first controller due to EMI problems, so now I am building a new case that is a metal body rather than an MDF case.
I will download the latest version, I am running the version previous.
I am not sure what may be causing the problem, I disconnected the vacuum in case that was a problem, and found that it happens randomly, sometimes at the beginning the spindle will move to position and then all movement is lost, spindle still spinning and I have to shut the computer down as I can’t close Estlacm or do anything at all. Other times it has come up with a USB error and yet I am still using the same shielded cable with a ferrite bead that I have been using with version 11.
I wont be able to test for a while as the machine is being updated and being serviced after a several years of use with version 11
complete crashes where you need to shut the computer down are always “real” hardware related USB issues. In those cases the USB driver itself crashes - something outside of Estcams control and influence.
The “soft” crashes where you can still close Estlcam and restart are also almost always real hardware related crashes. There is however a category of errors that can be caused by Estlcam itself that sometimes appear like USB errors but are actually caused if I messed something up in the communication protocol like sending data out of order or task collisions where a new command is issued before the last completed.
This kind of error is something I’m very weary about and take a lot of precautions to prevent from happening.
But due to the several legacy hardware / firmware variants Estcam supports I still wouldn’t be too surprised if I got something messed up there.
However: those bugs are usually of the “Use hardware X, with configuration Y, then do action A followed by action B and now the program will crash” type - not just random crashes.
When the new controller is ready after Christmas I will test again with the latest version of Estlcam that I have now downloaded.
I really suspect my hardware as I have learnt a lot over the years since I built it and often wanted to rebuild to put some better features and EMI protections in place. Now is the time.
I have really and truly enjoyed using Estlcam 11 since getting it years ago, it has served me well and has produced many items with almost no failures.
This new version so far I have seen many improvements and am still learning all that it has to offer.
A few things like which I have mentioned about the readability of the running line list I think could be improved, maybe a change of colour to the text so that it is in contrast with the background and maybe a larger font.
