Advanced Search

Hey group, 
Thanks for the help so far. I rewired my setup so that it looks nice now, but I have stumbled upon an interesting problem. Here is the description:

I added an earth connection to the power supplies and inside my breaker box. I rewired everything, and it was time to wire the home switches. Previously, I had wired them on the power supplies, which were for the motors, but now I got an extra power supply for them specifically (24V). 
I wired them 24 from the power supply to the normally closed AZ7121 home switches and from there to the Mesa 7i96s inputs (the optically insulated ones with the LED). For some reason, they were very dim, and the home switches were not working during home all. I started checking connections, and it seemed to be an Electrical problem.
First i found out that if i distributed how i wired them and placed them on multiple power supplies they lit up better.
Next i saw that the Init LED on the mesa card (RED LED) was on
Next i realized that if i took all of the input wires except one (the wires that went to the inputs of the card for the limit switches) the one input LED became dim, But if i simply plugged in another wire from another home switch into another input (but disconnecting it from its power supply, simply leaving it hanging) the LED on the input lit up (dimly) as well. 
Next, I opened the breaker box for the CNC machine and saw that the Earth connection was touching the metal rail on which the breaker is connected. Now, there was no visible connection of a Line wire to the rail, but when I moved the Earth away from the rail and restarted the Mesa card, The RED INIT LED stopped. 
Now, potentially, the earth touching the rail on which the breaker was connected somehow was a problem. (Don't know why)
But right now I still have the same problem where the input LEDs are properly ON, only when I have 4 Home switches connected to 4 different power supplies.
Also, measuring from Line to the Earth shows 18V, if that means anything. 

It definitely seems that I have done something wrong, but Nothing seems out of order. If anyone has experienced something similar or has any ideas I am open to trying. 

Thanks

I did try to follow the trail:

The error string displayed in the pop up comes from here:
github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L1715
which calls
github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L1579

The actual error is returned from 'gcode.strerror(result)' which seems to be this c++ function:
github.com/LinuxCNC/linuxcnc/blob/master.../gcodemodule.cc#L964

Why a user entry for a float value would be passed through all of that, I have no idea.

I had similar problems with my toolsetter, and initially used an AND gate - until the time I forgot to enable it (I used a manual signal, not motion.*) and crashed my toolsetter.  Then I tried smoothing, which worked OK.  It turns out the toolsetter is a good seismic monitor, and trips when I have issues with toolchanging

However, my comment here is... have you considered using a dummy probe move to retract the probe?
 

Cheap chinese magnetic encoder E6B2CWZ6C, 2500 P/R (10000 quadrature counts), spindle speed ~1400 rpm at left and ~60 rpm at right. Halscope shows velocity in rotates per second.
 

This is indeed a much neater method, great! I also solved it quickly and durty with an AND gate. But creating your own component is much nicer in the Hal code.
If I have an evening off, I'll play around with creating a comp.

Which LinuxCNC version? Not that it probably matters as I don't see much difference in this area.

I think that the dialog box is created here:
github.com/LinuxCNC/linuxcnc/blob/master...cripts/axis.py#L1643

With some TkInter stuff in the backgorund that I don't really understand.

But, I don't see where "file not open" comes from. There isn't normally anything in that area of the dialog, I don't think? (unless you know better?) so I can't even find a hint of which file isn't open.

Thanks for your analysis. If you feel so inclined, feel free to add this to the issue tracker: github.com/LinuxCNC/linuxcnc/issues

It would be even better if you could work out a fix

TripleM wrote:

I adapted it for myself, but I just wanted to ask if there was a specific reason why the order was chosen that way.

 

I just hadn't noticed as I don't have a tool-changer. It's that simple. No considered policy decision. 

It's hard to say without testing. There may be improvements to be made with isolcpus and other tweaks too.
If the board you get matches the one have with 25k latency then you should be able to step at about 5kHz (theoretical is max is 40kHz with a 25k base thread, but the differences in motor speed between every 5th cycle and every 4th and so on are more than the motor will follow)
With 4x microstepping 5kHz is about 375rpm at the motor shaft. Or 1800mm/min with a 5mm pitch screw..
You might want to start with software stepping / parport to get going, but it's not the best solution. If you are using a paralle port already then a Mesa 7i90 can be used to massively increase step rate and smoothness, and it adds a lot more IO too. There are other options from Mesa too, as well as from Pico systems and you can also look at the alternative firmwares like Remora for alternative hardware.

The release notes say that Ubuntu 24.04 is supported, and the issue you had looks
like a problem with  the XML project file, so I'm not sure whats going on.

Did you apply the latest patch?

If I get a chance, I can post a 7I96S Efinity 2025.1  project file
( I'll change something so the IDE re-writes the file )

Does this version leave existing configurations using scarakins unaffected? ie, is the new behaviour a strict superset of the area of correct behaviour of the existing kinematics?
If so, then can you raise a pull-request to update the current scarakins at github.com/LinuxCNC/linuxcnc

If the behaviour is different, then please raise a pull-request to add the new kins alongside the existing (scarkins2 for example)

The reason for this is that we try not t break existing configs through our updates. Anything that is currently working has to work at least as well after the update.

Hello,
I am working on a CNC mill with 4x Lichuan LC10E 23 bit absolute 1000W Servos. Setting up worked quite well following the tutorials and using the Marco Reps EL8 config and working from that. The machine is running and even the gantry is working. Now I am trying to tune the servos which turns out to be troublesome. After trying to get the following error down for a few hours I am left with a rather big F-Error during moves. The Error is scaling with speed. With 10000mm/ min I can't get it below a Value of 4.5mm. With 5000mm / min I can't get it below 2.25mm and so on. I tried changing almost every setting on the drive but can't get the F-Error any lower. So my last guess is that there is something wrong with the Ethercat timings or configs. Is it possible that this is a delay in ethercat between sending the position command and receiving the position feedback? Any help is appreciated
Best regards
Alex

Thanks. I'm looking to buy Asus Prime n100. How do you think will it have nice software step generation?

Did you say yes to the pop up dialog?

Like everything else you will only hear people bitching and moaning, the happy ones are usually pretty quiet.

The standard magnetic sheet works to begin with but over time it degrades. Creality make a textured glass sheet which works really well.