Advanced Search

my1987toyota wrote:

Ok it is officially January 1 2026 in my area and fusion 360 is still working on my Windows 10 machine.
Will it stay that way through out 2026? Don't know. 

Post from Autodesk forum:Microsoft will end mainstream support for Windows 10 on October 14, 2025. As outlined in our official Autodesk announcement, Fusion will still run on Windows 10 after this date, but:

• Windows 10 will no longer be a supported or validated platform for future Fusion releases.
• Autodesk will not guarantee compatibility, bug fixes, or product support for Fusion on Windows 10 after October 14, 2025.
• Fusion will not support Windows 10 LTS builds beyond this date, as Fusion follows Microsoft’s General Availability Channel.

So F360 will run on W10 for now, but my interpretation is that if there are issues due to F360 updates Autodesk isn't going to fix them.  Eventually F360 will stop working completely with W10, just like it did with W7 & W8 a few years ago.

As I mentioned early in this thread, I've moved to Win11 LTSC in the last month and am happy with it.  No AI, no telemetry, no spyware, no junk, no suprise 'feature' updates.  Can load it with zero MS add-on's.  So far it's been clean and fast.

Not an apologist for MS or Windows, but for those who must remain on Windows like myself, the Enterprise LTSC version seems to be the least objectionable option.

Maybe have a look at this:
askubuntu.com/questions/524384/how-can-i...epending-on-activity

36 bit IN TRUE hm2_7i97.0.pwmgen.00.enable <== x-enable
36 float IN -2.5 hm2_7i97.0.pwmgen.00.value <== x-output
36 s32 RW 1 hm2_7i97.0.pwmgen.00.output-type
36 float RW 10 hm2_7i97.0.pwmgen.00.scale

With these settings you would expect about -2.5V output of analog out 0

Possible reasons to not get about -2.5V

Looking at the wrong pins

output overloaded

5V 7I97T supply low

Damaged 7I97T

Hello Chris, i would really like the jog increment pins qtdragon.jog-linear-increment and qtdragon.jog-angular-increment. But i cannot find them, I'm running LinuxCNC 2.9.7. I have also searching through the master branch of QTDragon-HD, without luck.

How could I get the latest version of QTDragon-HD installed to my LinuxCNC?

Br. John

wow it works pretty well!

great job

there is some peaking but much less then I expected ... servo period is 250 000ns

I reduced BASE_PERIOD down to  50000 ns and peaking is weaker ... 

Testing at real setup isolated last core is with cold system latency 12.37us 

Just to be clear, everything is working as expected. And I do know how
to disable the screensaver.

What I would like however is to tell the screensaver that I'm still
using the computer whenever I turn the handwheel. Sort of telling the
system I'm hitting an unused key on the keyboard.

I'm sure it's possible, since that is what mpv/mplayer etc. also do.
I would like to do the same from linuxcnc/gmoccapy. If no one has done
that yet, I'll have to figure it out myself.
 

tommylight wrote:

I have no power for the last 3 days so using the phone makes it dificult to quote stuff with this editor, but in short:
-i have PlasmaC in daily use in over 10 machines, users got used to occasional stops and are OK with it, luckily rareley happens, i think it is 2.8.4 version.

Tommy, the last commit to the PlasmaC component for 2.8 (that was not just a version rev) was December 15, 2020. I'm not sure why you expect anything from that branch that may be a bug to get fixed. I can tell you for sure that I have 0 interest in squishing bugs in 2.8.

Certainly many improvements have been made to PlasmaC in 2.9. That said, even from a Qt/PlasmaC perspective, we haven't pushed any changes to 2.9 since ~August 21, 2024. But it's worth noting that component hasn't seen a ton of changes in 2.10.

-PlasmaC has 4 or 5 ways of disabling the THC, most are useless, except VAD, and void lock sometimes. Right now i can not think of any other valid use case.

From the 2.10 component code:
Main GUI disable
Disable(and enable) via G-Code
Velocity Anti Dive (sometimes called Corner Lock)
Void Lock
Mesh Mode/Ignore Arc OK

Personally don't see any of those as useless, but you also aren't required to use any of it.

I will tell you that I am the reason for Mesh Mode/Ignore Arc OK, because it would be impossible to cut expanded metal otherwise, something my Hypertherm is very capable of, and I do use this feature from time to time.

BTW default should be at 60-70%, not at 95%.

For QtPlasmaC, Cornerlock/VAD is defaulted to 90%. It's on the PARAMETERS tab as "VAD Threshold", luckily you change it once, click "SAVE" and it stays as your new default . It's literally impossible to make a default that works for everyone. If I change it to 65%, there will be other users telling me it should be 90%. That's why it's tunable.

-what should i monitor for the issue where the torch keeps going down till float switch triggers during cut

If you are talking 2.9 or 2.10, then I would say without knowing what is causing it, I would just be guessing. But, I would want to know, is the voltage staying constant, and the plasmac component is commanding the THC down anyways? Is my voltage erratic? Etc.

As a start, I'd plot plasmac.arc-voltage-in with plasmac.move-down, plasmac.move-up, and plasmac.current-velocity. If you're telling the component what voltage you want it to shoot for, then I'd add plasmac.cut-volts. If you're using auto-volts then I'd want plasmac.target-volts.

happens often and ruins the nozzle. More often in QtPlasmaC but that might be just luck

Phill added plasmac.low-cut-volts as an attempt to prevent this. You could try setting that to prevent it form diving into the material.

-what should i monitor for the issue where the machine moves to a cut position and just stays there? This happens sometimes even when doing a manual cut where pressing F9 shows the machine running on screen but nothing moves. DRO does not change, machine state does. Again this happens a lot on QtPlasmaC, do not recall this happening on PlasmaC so might be a QT thing.

Again, I'd want to know if motion.eoffset-limited goes true when this occurs. I am also curious what state it's stuck in, so I would want you to turn on plasmac.debug-print before starting any cutting, etc. and copy and paste the terminal output from when it hung up.

-i think i have an old config for QtPlasmaC on a laptop for my machine, i can upload that if you think it might help.
-i absolutely have no issues with intelectual property, i do and will post everything i do personally, as can be seen from many posts here, i am strictly Open Source everything, and i did reject any job requiring me to sign an NDA
Ooops, not very short

If you have it, I'd look at it. Sure.

Thanks, @Surmetall. I took a closer look at your solution and it looks very clean.The main issue on my side is that it appears MAHO did not use the same motor construction as Deckel.



I’ve been trying to find maintenance or service manuals to see whether the front bearing housing of the original motors could be reused, but so far I haven’t had any luck.

Another complication is the very limited space available for the Z-axis, which makes motor placement quite challenging. I’m planning to make a short video soon to better illustrate the space constraints and the problem I’m running into.

Happy New Year!

github.com/grandixximo/linuxcnc

I've committed a working multi axis s-curve optional trajectory planner in this fork, happy to get some feedback from the community, it is based on master.

Here is my s-curve, go wild...

github.com/grandixximo/linuxcnc

I have not build it yet, but it should work, test and let me know,

happy new year!

Yes, if you have good latency it does not really matter how close you are to the sync0shift window, as long as you never jump ahead and back, I also had to force the issue to come up and induce latency in my system by opening graphical intensive applications. But I believe my fix is a real game changer for running ethercat on something that is not super latency optimized, and not see the grinding issue, I hope the community will receive it well, I'm here for any bug fixes or whatnot...

github.com/grandixximo/linuxcnc

I have not build it yet, but it should work, test and let me know

Edit:
There were build errors, should all be fixed, built on debian 13 no issues, have a simple xyz test configuration, it works with more joints/axis no problem, xyz just quick and simple.

Quoting from the Xfce tour:
"Screen Locking
There is no dedicated "security" tab anymore. Lock screen management was massively simplified and "Light Locker" was dropped. "lock-on-sleep" is now synchronized with xfce4-session and xfce4-screensaver.

Screen locking settings are now only handled by xfce4-screensaver to avoid conflicts. A button to open xfce4-screensaver-preferences was added"

That gave me the idea "Power Manager" does nothing anymore. So I installed xfce4-screensaver and set the screensaver to blank and lock after one minute. I watched it for 6 minutes and it stayed lit and didn't lock.

Next I set "Power Manager" from "never" to blank and lock after 1 minute. It blanked and locked after 1 minute. I set it back to 'never'.

We'll see how it behaves over the next couple days, but it appears installing xfce4-screensaver allowed my power manager settings to work but the screensaver settings didn't work. Go figure.

I do get the idea xfce4 is experiencing a major rewrite and expect over time there will be updates that make it behave.

Edit: It appears this is the associated bug report:
bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034607

Ok it is officially January 1 2026 in my area and fusion 360 is still working on my Windows 10 machine.
Will it stay that way through out 2026? Don't know. However given the bad press of
Windows 11 Autodesk would do well to let fusion 360 run on Win 10 for a while longer.
So we will see.
With that said Have a Happy New year every one.