Advanced Search

Hallo,
ich betreibe hier zur Zeit eine Eigenbau Portalfräse mit GRBL, genaueres über die Maschine gibt es hier .
Dort sind auch die Probleme dazu angerissen, prinzipiell genügt mir diese Lösung völlig, zum Killer wird das ganze aufgrund der Störungen der Frequenzumrichter. Technisch ist da zwar Abhilfe möglich, das würde aber der Mobilität der Lösung nicht zugutekommen auf die ich nicht verzichten kann.
Als Lösungsansatz hatte ich über eine Ethernetverbindung PC - Fräse nachgedacht, sowas ist deutlich robuster. Inwieweit es funktionieren wird wird sich noch zeigen müssen. Daher wählte ich einen günstigen Ansatz für den Test.
Momentan ist ein Arduino Uno mit GRBL drauf in der Fräse, ein MSI 9A35 als PC, das sind die komplett passiven Windboxen im Alugehäuse, schön robust mit Linux und BCNC im Einsatz. Im Grunde ideal für solche Dinge.
Das der 9A35 nicht genügen wird war mir klar, daher habe ich einen 9A45 beschafft, das ist ein dächte ich 1,8Ghz mindestens Zweizylinder mit 4 GB RAM. Der Charme der Dinger sind auch die zwei Onboard Netzwerkschnittstellen. Eine davon stellt die Verbindung zu einem Novosun NVEM V2 Sechsachscontroller bereit, die Firmware für Remora ist schon drauf.
Der PC hat ein installiertes Linuxcnc mit der nach besten Wissen und Gewissen installierten Remora Erweiterung. Soweit sogut, der NVEM ist via Ping auf seiner Adresse erreichbar. Linuxcnc scheint den auch zu erkennen, trenne ich die Verbindung zum NVEM oder schalte den aus kriegt das die Software mit und geht offline.
So, nun ist es so, ich brauche etwas Hilfe zur Selbsthilfe, was muß ich als nächstes tun? Was muß ich als erstes konfigurieren, oder anders gefragt was muß ich überhaupt konfigurieren - versuche ich eine Achse mit der Testkonfiguration in Remora zu bewegen gibt es eine Fehlermeldung Motor x Positionsfehler - x steht für die Nummer der Motorachse.
So wie das also aussieht fehlt da noch ein Stück Konfiguration, ich denke nicht das das Problem am NVEM zu suchen ist.

Gruß
Mario


 

your job is amazing ... i am watching the scope curves without the breathing ....

conculations of polynomes of 5th grade probably take some power ... for more axis at same time can introduce jitter and at cloud of point it will be most visible ...

I am actually testing it at 1000us 500us and 250us which is most commom industrial scan time ... intel core duo, i5 and i7 ... every has different computation capacity but jittering are present during clouds 

I will take some more time and I will post outcome 

thank you for your job! is very interesting 

Wow! Thank you for testing, I actually never looked at the effect on the servo thread, I was more concentrated on velocity and acceleration changes, it is an interesting testing method, there maybe further possible optimizations, possibly some c++ tricks I'm not aware of, but in current state is the best I could come up with, and it is IMO respectably decent, nice to get some validation...

I have edited the original pid.c to include a minoutput pin, and now it works like a charm. There is no windup and zero overshoot on the way down, just like on the way up.

To install it, open a terminal in the folder containing the modified pid.c and run:

Then set the minoutput pin to the minimum ADC value your setup can handle. In my case, this value is zero, since I am using a software pwmgen to generate a 0–10 V signal:

This is the piece of code I have customized:

video showing it functioning in sim and how to test:

load tool 99 probe tool, move probe tip somewhere clear in the work envelope, use inside corners probe page and select a single move probe routine, trigger the probe by clicking the probe graphics probe tip. try jogging to see if sim repsonds correctly.

 

if you still have probe basic installed, would you mind running a test in the simulation? I am running a sim test here and cannot reproduce the error using the on screen probing buttons. i can probe a point in space and immediately jog afterwards using both the keyboard and on screen buttons. so its hard for me to discover why your install is not responding the same. but if you test the sim and the problem does not exist then it would be something in your configuration most likely.

when you say locks out, were you referring to keyboard, on screen buttons, or both?

Yes, the PWM value (from the PID component) should increase as the position
error increases.

Did you check the 5V power?

Are CR23 and CR27 (Yellow LEDs near the center of the card) both fully illuminated?
(these LEDS indicate the analog +16/-12V power supply operation)

The reason I suggest at least 20% extra terminals, is that you will certainly add a pendant, and most likely a 4th axis, but once you lay out your cabinet, it will be full (they always are) so no expension built in means a PITA to add expansion later. Ask me how I know
Cheers,
Mark.

Furthermore, the Mesa disconnects after approximately 5 minutes with these values. The 1A Ff fuse doesn't blow, but the wire deforms. I suspect that due to increased contact resistance, the voltage at the Mesa is no longer sufficient.

When I move the axis further using the LinuxCNC interface, the value keeps increasing, as if it were the value of the distance traveled... for example, -77... Is that supposed to happen? I'm also only getting 0.35V at the other PWM outputs, both with and without the power amplifier connected.

I will definitly check that, when the machine is back together. At the moment i cant power on the machine because most of the wires are disconnected.

tommylight wrote:

-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma

Done.

Master Branch only:
github.com/LinuxCNC/linuxcnc/commit/1d62...9fc99abfe5068e608288

There is some good information in there, thanks.

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.