Advanced Search

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!

But no matter what the value is set to or how I change the scale, the Mesa only ever outputs ~0.35V. Or are there jumpers or something similar on the Mesa hardware that I need to adjust?

Thank you so much for your help! I really appreciate it.

The output voltage should be PWMvalue/PWMscale

So if PWMscale is 10 the output voltage=PWMvalue

So it's December 31st 2025 and I am curious if Fusion 360 will actually stop working on my Windows 10
machine at 12:00am January 1st 2026.  As I write this message it's 3:20 pm and currently Fusion 360 is
still operational.  I will keep it logged on to Linuxcnc and Fusion 360 and update on my findings.
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?

i reused the original mayr safetycouplingers on my FP:
forum.zerspanungsbude.net/viewtopic.php?t=47794#p575058

Still looking for a freelancer to help get a tool sensor setup in software

Thanks guys. I am collecting up the wisdom of the crowd, and will try to work through everything systematically.

Doesnt work in sim either

That bug should be resolved in recent builds of the framework.  Its not a monokrom bug. It came out due to an errant print statement, I think inside the vtk plot code.

"What's the first rule?  Do NOT use print statements in the code.  Use LOG.debug"

I'm talking about the PWM value. So this value is a voltage value? Like 17V? I know how to limit this value. But I never measure this value on the Mesa. It's always only 0.35V as soon as I enable it.

The output voltage should be PWMvalue/PWMscale

How do you setup a tool sensor exactly? I cant seem get it right after a week of trial and error of setups, parameters changes. This is not a wiring issue or a debounce issue but a setup issue.

Current Setup:
LinuxCNC 2.9.4
2" tool sensor on the bed
Attached is my setup files

From this document  linuxcnc.org/docs/stable/html/gui/gmocca...uto-tool-measurement  I cant tell if I am doing something wrong or where the discrepancy is.

This example setup would cause the Z axis to come down to get to the -20 setpoint. This results in a crash into the probe and a "Probe tripped during a non-probe move" would appear. The solution to this was to set the Z to 0 so the probing search would start immediately

For this next issue is touch off x and y (not z because the document says to press "Block Height") I immediatly get a error when pressing x or y touch off. 

"G-code error in change.ngc near line 76, file ended with no percent sign(5) or program end (m2)"

Now if I just ignore these errors I get the same error when doing a tool change after it probes it.