Advanced Search

This is really awesome work. I would stick to the igc driver which is real time when generic isn't
But from what I am hearing, optimising for system and network latency will probably avoid the issue.
I have a video about that and one user reports he got latency down to about 6 usec following my tutorial.
I suspect by running a latency optimised system has meant I have never experienced this.

You CAN disable completely screen saver and still have the monitor go off after a while, use "power options", they are not the same thing.

Sorry not much help as I am in British Columbia, Canada ATM so  similar time zone to the OP (not 2026 yet!). I cancelled my F360 subscription and have been using Onshape to create STL files for 3D printing. I think when I get back  to needing CAD, I will try Freecad on Linux (Did I tell you I detest Windows?) There is collaboration between our devs and theirs starting with their tool handling API so I think it will be worth playing with.

unknown wrote:

So the issue is the screensaver is doing what it is designed to do ?

I think so

Well it's almost 8:00pm  or 20:00 here in Florida. Just 4 hours to go. Some sporadic fireworks here and there. Though tonight
I think I will have a drink, not that I see much to celebrate. It just seems fitting given what 2025 has been.

So the issue is the screensaver is doing what it is designed to do ?

Thank you for the files!
That is not a documentation, only a lot of not really understandable words.
The connection and reading I have tested.
Now i have to figure it out how to scale it correctly and how to transfer to the VFD the input commands.

Sorry, I am definitely not an expert in this. You can take a look at my config and the documentation here:
linuxcnc.org/docs/html/drivers/mb2hal.html
Attached is my mb2hal ini file and the spindle bits from my hal file. I am not an expert but I was able to figure it out just with the VFD manual and the documentation.

I just checked master has new option for

[TRAJ]
NO_PROBE_JOG_ERROR = 1

in the .ini file, you could use that to check if the issue goes away?

you have to make sure your version supports this, it's just been added 4 months ago

Yeah, sorry, might have mixed you with PhillC, i have a very nasty habit of messing up names... and most probably you would too if you lived here where every person has one of 15-20 names used here. I was convinced this is my problem till about 15 years ago when i noticed i have no issues with complicated names that are not common here, but still the habit lingers ...
Also a non drinker.
23:58 here and the fireworks started....
Happy new year to all.

Not I, I'm Linux only. Also a complete non-drinker, I had my share enough in my teens and early 20s.

my1987toyota wrote:

With that said I am sure it is already January 1st somewhere in the world . Has any one tried seeing if
Fusion 360 still works for them on Win 10?

RodW and "unknown" are in Australia so they are already in 2026, and i think both used Fusion360 at some point in time, and they both monitor the "recent topic" section of this forum, so maybe they chime in, granted new years day so might, might be hangover ...

Yes, it is there, unfortunately to test the original code you have to have subpar CPU latency, have some glxgears running, and halscope to simulate/induce bad latency, then you probably have to restart a whole bunch of times, in my case I methodically restarted 100's of times, moved and checked the ferror while moving for the grinding, the better your latency is the less probability you will land on the bad window randomly, by inducing some strong latency on my system running graphical processes which I know give me spikes, I was able to get grinding in the ferror about 20% of the times, without purposely inducing latency I would see it 5% of the times, and I'd really have to look for it with halscope, because opening halscope and plotting the ferror would actually make the latency worse, and the consequently I spotted it more often, without halscope running I could potentially see it only once every 100 restarts if ever, which makes the issue incredibly rare with good latency, the original code was good at syncing, but phasing was random so if you ever were to end up in the grinding window, a restart would have fixed it almost always, phasing was random as far as I tested before my fix.

Hard to tell whats going on could be you have the wrong output
or there's a hal or hardware issue. To determine whats going on,
can you run LinuxCNC, enable motion, and then in a terminal window run:

halcmd show all | grep pwm > pwm,.txt
 
and then post pwm.txt here





 

Do you have the schematics for the drives?
-
This is just thoughts on how i would go about checking this, might be OK now that i had some time to analyze the symptoms :
-first check the power going to EXE boxes, is it the same voltage on all 3 or 4 of them?
-is the power for the EXE coming from the Indramat drives?
-if yes, are they all powered from the same rail or do each have it's own power regulator?
Assumption: given the info i would check the Indramat drive for rust on the EXE power rail, it is just to convenient given X is fine, Y faults at the end (meaning a bit lower voltage so accumulating PID error), and Z faults immediately, this also assumes the voltage regulator to be near the X axis drive/feedback and furthest from Z axis drive/feedback
-All of the above is valid if drives/motors use tachos, so same checks on the tacho feedback voltage regulators.
-
Stopping here for now, to much assumptions and unknowns that need confirmation or denial!