Advanced Search

Mesa have a product called spinx or similar, converts digital pwm to isolated analogue out.

The new image I'm working is created using the same utility that Raspberry Pi company uses to create their own images, so basically raspios with a real time kernel and Linuxcnc pre installed. Far more raspios than the previous.

I recently bought some Chinese linear magnetic encoders with RS-422 output and connected them to my Mesa 7i76 and 7i85 boards. Everything mostly works, but I’m having a strange issue with the encoder status LEDs.

Each encoder has LEDs:
Blue = IDLE
Red = ERROR

Here’s what happens:
When I power on the machine, the ERROR (red) LED turns on immediately.
If I unplug and replug the encoder connector, sometimes it switches to IDLE (blue) — but not always.
If I disconnect and reconnect one of the signal phases (A or , I can get the IDLE state.
If I power the encoder alone (without connecting signal lines), it always shows IDLE.
It looks like the signal lines or differential inputs might cause some initialization conflict when LinuxCNC / Mesa powers up.

Has anyone experienced something similar with RS-422 encoders on Mesa boards?
Any advice or tests to help diagnose this would be appreciated.

www.youtube.com/shorts/ciVcxrlmMIA
www.youtube.com/shorts/__zn74D7OyM
There was another one....
Thing is those laptops are way more useful and cost less than RPI with touchscreen. But do not expect them to always work, i have several (had 30 or 50 or 100 !?!?!?) that worked perfectly, but you can bump into an utterly useless one.
The choice is yours, i am just making it harder!

I have several simpler LS-173E drives, which only have the RS-485 command interface. I had a project to implement LDCN in a microcontroller for standalone operation, but it's on the back burner this year. No opinion on feasibility with LinuxCNC, but I stumbled across this project that might be useful:

"Linux port of Logosol's LDCN with Python bindings"
github.com/cversek/linux-ldcn

I have a large number of LS-173E drives, which seem almost identical to the LS-131-2010 in the picture. Unfortunately these simpler drives have no step/dir or analog input, so the RS-485 command language is the only option. Logosol very admirably continues to make their (now quite old) software and documentation freely available for download. I've tested the drives under Linux using their software in a Windows XP VirtualBox VM, with USB passthrough to an RS-485 dongle.

Thank you both,

Andy, I was meaning using the remora encoder module, but I appear to have misread/missed the part where it would not support count mode like the LinuxCnc one. I will have to stick with the LinuxCNC one, which is working, but only up to around 1900 rpm on one of the RPi pins. likely a base period issue.

Murphy, thank you, that is unfortunate that the 500 is needed for hardware. I don't mind bypassing the opto's or replacing with a faster digital equivalent even if external to the 500. but all that can wait until I sort out a quad encoder of some description.

Hat es vor der Installation von meiner Routine funktioniert?
Einen Werkzeugwechsler hast du ja scheinbar nicht, hast du den manuellen Wechsle in der HAL drin?
Funktioniert die manuelle Vermessung über [Touch off current tool] bzw. M601?

My effort is to learn g-code subtleties that are new to me as well as to improve my python coding abilities.  Consequently, I trying to fully automate the measurement process. To that end, I decided that I could combine both Andypugh and JT's approaches to first capture the data with a g-code script then process it with python.

As I studied o-code subroutine examples I attempted to use an internal subroutine with Andypugh's suggestion for a more elegant approach. I've attached my code for your inspection. 

When I load the code into LCNC this warning is raised:

 Near line 40 of ./check_level.ngc "Bad character '>' used". 

I'm lost as it appears that the code follows the examples in the documentation. Please help me understand the issue.

Kind regards

I'm loving hearing this, as I've never used RPI I was interested for two reasons, one because it's very compact and the other because it uses its compact and cheap touch screens, but I'm afraid I'll have difficulty as I've never touched one and I need a lot of help from you... In parallel to this subject in relation to 7i92H, how do you do in relation to the spindle since it doesn't have a 0-10v analog output?

Hi Andy,

Thank you — your reply has pointed me in a couple of useful directions.

The current logic comes from another Boxford conversion running a Pi, though that one was a 125 (not mine) rather than a 240. That said, I stripped out most of it and was still encountering issues.

It’s GPIO14; I just hadn’t updated the comment yet as I’d moved pins to double-check something.

I have, however, found the G95 issue. The problem was that spindle.0.speed-in was connected to encoder.0.velocity-rpm instead of encoder.0.velocity, so the motion planner was seeing a speed sixty times faster than expected. Correcting that resolved the issue.

Most of the encoder speed problem stemmed from not having a sufficiently fast base frequency, which meant it was under-sampling and missing the index input. Moving the index pulse to an EC300 Remora pin has fixed that.

It’s not perfect, but it’s enough to get most things running until I can sort out a better encoder. I’ll probably follow your suggestion and add a second sensor offset by N+¼, although that will take some planning — the slot sensors are quite bulky, so getting them close enough will be tricky.

I’ve had to retain part of the spindle logic, as my servo input for analogue speed and direction is –10 V → 0 → +10 V. Because of that, I’ve kept the abs portion to strip the sign so that the DAC section only ever sees a positive voltage. The spindle is then reversed using two relays that invert the normal 0–10 V signal.

Unfortunately, I’m still not getting a stable speed above 1900 rpm. I suspect this is due to the sampling of the 100 PPR disk — when I decrease the base period, the speed stabilises, and by reducing it further I’ve managed to get stable(ish) readings up to around 1900 rpm. Above that, HAL Scope just sees phase A as high rather than a pulse train.

The good news is that feeding using G95 works when using the MDI.

The bad news is that no programmes will run. I get some movement when single-stepping through, but no feed. I now suspect this is because the programme uses CSS, and given the above issues, the control isn’t seeing a stable enough RPM for CSS to function correctly. I’ll try running the programme without CSS tomorrow to confirm.

If that doesn’t help, it’s probably a “spindle at speed” issue — though that signal does appear to be set correctly when the spindle reaches speed, so I’m not entirely sure.

Yes i am, i have 3 or 4 of those in daily use, 1 with Proma THC150 and others with Mesa THCAD.
I also have a china one with same electronics and pilot arc, the HF type, i intentionally wired the THCAD10 to the main terminals with 1MOhm resistors on each side, still in daily use for nearly a year, no issues.
The thing is, with correct wiring and grounding and shielding, it works fine, but any wiring error will result in burnt electronics the first time the torch fires, hence i refrain from advising such things.

Maybe this thread would get you going in the right direction.

forum.linuxcnc.org/subroutine-library/51...asic?start=10#336942

It works now...
I have two network adapter. One intern and one USB. My Internet was connected to the USB adapter. This doesn´t work. I switched to the intern adapter and now itś fine...

Are you sure, Tommy? It got HF start.

www.linuxcnc.org don´t work
Reddit    don´t work
Youtube work
Google  work

My Windows Laptop (WLAN) and my Smartphone (WLAN) have no problems