Advanced Search

thank you for the quick response!
I am not sure what you mean by beginning of the next cycle.
If I remember right, the samling of rows is done with 3.7kHz scan frequency and each row is measured for ~30µs.
From my understanding the inputs should be sampled at the end of each cycle so here ~25µs after the output is set to low. So right before it is set back to hi-z.

I have a dual-Y configuration on my cnc, and what I have is two limit switches - one for each motor. The config has a separate section for each *motor* so you can specify the homing offsets independently. In my case, the two entries differ by 0.036 to bring the gantry into square. So I'm using your #3 solution I figured out the offset value by homing, measuring how off-square I was, updating the config, and re-homing; repeating until it came out square.

Your alternative is to mechanically tie the two motors together (or use one motor and two screws) and tell linuxcnc you only have one "motor"

Looks like the drives were originally setup  for up/down
(Pulse F, Pulse R in the drawing) mode so you might try
setting the 7I96 stepgens into that mode. 

(step_type = 1)

Why are you using the stepgen board?

I've been working on retrofitting a Soltera TDD1000 CNC drilling machine with a Mesa 7i96 and 7i77, but I’m running into an issue where the servos only move in one direction, regardless of the direction I command in LinuxCNC.

I connected Encoder 0 on the 7i96 to the Minas A5B (MDDKT3530E) servo driver via the X4 connector. Here's my current wiring setup:

    Mesa ENC0 Step- → Minas PULSH2 (Pin 45)
    Mesa ENC0 Step+ → Minas PULSH1 (Pin 44)
    Mesa ENC0 Dir- → Minas SIGNH2 (Pin 47)
    Mesa ENC0 Dir+ → Minas SIGNH1 (Pin 46)
    Minas Pin 7 (COM+) → 24V power supply
    Minas Pin 41 (COM0) → 0V (power supply ground)
    Minas Pin 29 is jumpered to Pin 41 (0V)

I attempted adjusting some parameters on the Minas A5B (P0.01, P0.05, P0.06, & P0.07) but none of these changes resolved the issue. (I’ve attached the current parameter set from the driver.)

I also tried swapping the DIR+ and DIR- lines on the Mesa board to see if the motor would reverse direction, but it still only moved in the same direction.

Using Panaterm to connect to the servo over USB, I confirmed in Test mode that the motor can move in both directions, so I suspect the issue lies somewhere in either the LinuxCNC configuration, or the servo driver wiring/configuration.

Has anyone worked with these Minas A5B servo drivers before? Any guidance on how to troubleshoot or resolve this issue would be greatly appreciated.

Attached are the current Minas Paramters, The Linuxcnc Configuration, and a PDF of the original wiring on the drill line.

That's how it works for the MESA, but the MKS OSC stepgen board works a bit differently.

I think it's continuously sending pulses and just switches the drive by the enabled signal.

 


If I remove the EN wire, it just starts running.
Maybe disconnect the EN wire and just toggle the CLK wire with the on/off relay? (that's the pulse signal)

ffffrf wrote:

What if one of your home switches is slightly higher than the other? Can you offset that somehow in linuxcnc?

Yes, you can, easily.
But that would absolutely not work with both motors coupled.

Easiest example which i am basing my machine off of is the APSX-nano desktop swiss lathe. It uses a dual motor Y axis with a coupler between them that holds various lathe tools. I uploaded a picture off of one of their youtube videos. My concern is that this coupler that holds the lathe tools is rigidly attached to both of the Y axis motors - how do you ensure they are perfectly height-aligned so there is no twist or torsion on the lathe-tool holding coupler. I understand you can use slave axis in linuxcnc but wouldn't this require you to ahve home switches at exactlythe same relative position on each separate axis? What if one of your home switches is slightly higher than the other? Can you offset that somehow in linuxcnc?

I'll take a look. Seems like the scan sequence needs to be changed
so the sample is done at the beginning of the next cycle so the full
period is available for settling time.

I think I downloaded it a few months ago. I just downloaded another one a few minutes ago.
I will install that one to see if the problem is persisting. I will reply back in a bit when I know
one way or the other.
stand by

This is still dragging on..... bloody hell.
When did you download the ISO?
2025-01-27 is the last upload date.
Whoever is building the image:
Clean the build environment before building a new image!!!
I am tired of repeating this.
But i am sure this was Debian's f@kup so i am cool again!
Debian should never ever have anything RPI related into AMD64 images, they had.
Edit:
And rubber ducky also means something else, so refrain from using it near PC/network security experts

Sorry, hope you can read that mess above ^

No clue what happened and attempting to edit any of it looks to put the entire thing in quotes. As if I don't have enough problems.....

hi,
i'm new i also have a mesa7i96 board.
in the next few days i have to configure the limit switches.
how can i launch halshow.
thanks
Milko
From Italy

PCW wrote:

Did you try pinning the Ethernet IRQ to the last processor?

This usually make a large difference in Network latency
 

With your script the irq go to 2,3 core!

Attis92 post=327432 userid=41888Yes, correct!
But I’m still having some issues with the config upload, which I’m currently investigating on the EC500 board.
If you're unable to change the config, you may need to erase the entire chip first:

sudo pyocd erase -c --target mimxrt1050_quadspi


Then flash the firmware again and upload the new config.


[code]sudo pyocd flash remora-rt1052-3.1.3.bin --target mimxrt1050_quadspi


This worked for me, but it's definitely not an ideal solution.

[/code]

[/code]
[/code]github.com/scottalford75/Remora-NVEM/tree/main/LinuxCNC - and now I am going to have to try and sort all that out with no real clue or set of directions. That is provided I did everything as I was suppose to and it all actually worked. I don't know how to test it other than try to get LinuxCNC configured and run it. At this point I will be happy just to see the Estop trip when the terminals are shorted on that input.

wish me luck