Advanced Search

The easiest solution for Mesa hardware is to use firmware that
includes stepgen index, then the stepgen hardware mimics encoder
behaviour at index detection.

Chatgpt and I have been working on this for quite a few hours now and I don't quite understand why this doesn't work with the out-of-the-box options... but I've learned a few things. If there is some easy way to fix this, please don't tell me. I don't want to know I've wasted all of this time.

JK, please do tell.

Here's what led me down this road:
1. Want precise homing.
2. Want to monitor for lost steps.
3. Full closed loop seems to be a no-go with the drive/motor/encoder combo I'm using. I may explore this more later.


Adding HOME_USE_INDEX = YES to the ini with stepgen it does a variety of very strange things. I can't give much detail on exactly what is happening because I've had some widely varying outcomes and it has been hard to track the exact cause and effect. It seems related to an issue with resetting the joint.x.motor-offset value at the wrong time. That's my best guess. I tried adjusting everything under the sun to get it working as expected and no luck.

SO. I think I have a solid solution. I'm typing it here to organize my thoughts before writing the hal and to share with anyone attempting the same thing.

The idea is to swap in the home switch input with the encoder's index-enable at the right moment. (When the index-enable is set high, it stays high until the next index pulse). For example with my X axis, the axis homes on the negative (left) side. The no-encoder homing procedure is to move left until switch trips, then move right until it releases and set 0 at that point. If I swap the home switch input over to the encoder's index-enable, see example below, after the first trip of the home switch the motor will continue to the right until the index pulse occurs and set 0 at that point.

From this: net min-home-x  hm2_5i25.0.7i76.0.0.input-xx  =>  joint.0.home-sw-in (normally low)
To this: net min-home-x  hm2_5i25.0.encoder.00.index-enable  =>  joint.0.home-sw-in (normally high)

The idea:

1. joint.0.home-sw-in needs to be connected to the home switch unless we're homing with the z pulse.
2. encoder.00.index-enable needs to be set (but not held) high at the moment the home switch goes high, and only while homing.
3. joint.0.home-sw-in must be swapped from the home switch over to encoder.00.index-enable.
4. after encoder.00.index-enable goes low, joint.0.home-sw-in must be swapped back to the home switch.

Logic layout (shorthand) tested and working:

home-switch > and2.in0
is-currently-homing > and2.in1
and2.out > toggle.0.in
toggle.out <=> encoder-index-enable
encoder-index-enable > or2.in0
home-switch > or2.in1
or2.out > joint.0.home-sw-in

This works although there are some issues when it comes to the feedback. Using encoder feedback (not with a closed loop PID) with joint.x.motor-pos-fb throughout the homing process doesn't work. Something about the timing causes a following error... if your following error is set reasonably tight anyway. SO. I found two options to solve this and they both have caveats.

Option 1:  Use stepgen-pos-fb only while homing, and the encoder the rest of the time. Gives you following error protection unless the axis is currently homing. Caveat is that if you estop and the axis moves afterwards, more than your allowable following error, linuxcnc will pop the following error and it won't go away until you restart.

Option 2: Use stepgen-pos-fb unless the axis has been homed. If homed, use encoder feedback. Using this in conjunction with "VOLATILE_HOME = 1". This keeps linuxcnc from popping a following error after returning from estop, because the machine will be unhomed after an estop which puts it back into stepgen feedback. Caveat is that you won't have following error protection until the axis is homed. This also requires an extra hal component (tof) to deal with the timing issue that has plagued me with following errors.

Logic layout (shorthand) for swapping the feedback, both tested and working:

Option 1-
stepgen-pos-fb > mux2.in1
encoder-pos-fb > mux2.in0
mux2.out > joint.x.motor-pos-fb
joint.0.homing > mux2.sel

Option 2-
stepgen-pos-fb > mux2.in0
encoder-pos-fb > mux2.in1
mux2.out > joint.x.motor-pos-fb
joint.0.homed > tof.in
tof.out > mux2.sel


Here is the actual tested and working code:
INI



Hal



Custom Hal, Option 2 shown


For reference and context:
This particular machine has a single limit switch on either side of each axis. One side doubles as a home switch with "HOME_IGNORE_LIMITS = YES" in the ini. 3 axis router, axis GUI, LinuxCNC 2.9.6, Mesa 5i25, 7i76u on P3 and 7i89 on P2.

It could be that I am an imbecile. However when I used MesaCT as installed per the instructions here using apt gnipsel.com/linuxcnc/mesact/install.html#install-with-apt. I did not get an anywhere near working configuration out of the tool. The stepper configurations were very incomplete. The feedback loop was not closed in fact the PID output was not even sent to the mesa stepper driver. 

I will post up my configuration files from the output shortly. 

If you don't have an added parallel daughtercard, you should normally not change the
installed firmware.

The default 7I76EU firmware is 7i76eud.bin, to re-install:

mesaflash --device 7i76eu --addr [card_ip_address] --write 7i76eud.bin --reload

where [card_ip_address]  is either 192.168.1.121 or 10.10.10.10 depending on how you
have the card setup.

 

I have a 7i76eu that I am using on a new lathe conversion. I must have something wrong with firmware or something on the 7i76eu. The configuration is set up with 3 encoders is what it says. I only have one encoder connected to the 7i76 on tb3. It is configured as single ended jumpers w11 w12 and w16 all set to the left position (up in my case). When I look at the inputs in halshow the A signal is showing up as the A signal on encoder 0, the B signal is showing up as the A signal on encoder 1 and the index signal is showing up as the A signal on encoder 2.

What do I have incorrect here. My mesa setup is a 7i76eu with just a 7i73 pendant smart serial card. I have one spindle drive, one encoder that I am using on the 7i76 two steppers and several io.

I downloaded the firmware pack from Mesa. I installed one that just had the 7i76in the name but no other cards. Which firmware should I use in this case? 

Not sure if this is a config or a firmware mismatch issue. Any help would be appreciated.

Working through this,

irqbalance was not installed by default in Debian since Debian 9 Stretch because the kernel now does its own rebalancing. In some case irqbalance has caused  instabilities. Accordingly any advice about irqbalance is obsolete. If you have installed it, you should purge it
sudo apt purge irqbalance

Also cpufrequtils is deprecated in Trixie and has been replaced by the  linux-cpupower package. to set your governor to performance, use ( I think)

I think I begin to see into how this 'extra joints' command flow works.

1. My ui will trigger homing via a "Home all" button. NOTE: Y1 and Y2 will need footpedal operation to complete the ram homing and they home simultaneously.

2. When homing is complete, the joint.5.homed pin enables the j5.limit3.enable to enable program control of that servo.

3. My ui sends a position to j5.limit3.in then j5.limit3.out feeds joint.5.posthome-cmd. This seems to be a position value (not velocity). If I am correct, that is what I need here.

4. The position from #3. feeds straight through to joint.5.motor-pos-cmd into j5.pid.input

5. j5.pid.output is a velocity command driving hm2_7i80.0.pwmgen.00.value

6. Feedback is in the form of hm2_7i80.0.encoder.00.position to joint.5.motor-pos-fb and to j5.pid.feedback

I attached a flowchart of this for reference.

Also, I did not see where you are disabling Energy Efficient Ethernet.  It is supposed to be disabled by default but this is not always the case. There are some flags that can be set in GRUB but they are driver specific. eg. igb.EEE=0 

I have not tested this but This is a robust way to ensure EEE is disabled on every boot. Create a new systemd service file:
sudo geany /etc/systemd/system/disable-eee.service

1. Add the following content, replacing enp6s0 with your interface name. This service will run ethtool after the network is up.

1. Save and close the file.

Reload the systemd daemon:
Enable and start the service:

Yes, i read thier manual 1k times.. it is pretty solid extraction of what we all need...

Yes I am recompiling everytime to native NIC driver as common e1000e or rtl8190too ... It works pretty solid for 8khz thread 
8190too are basically free stuff on the market right now it cost few bucks

There are native drivers for beckhoff too but I have never tried them yet ... 

I am not expert in this drivers ..but if it will improve my latency i need them all ...
 

I can't help here. I had a feeling that a linuxcnc filter was a program that accepted an input file and wrote out an output file so you should be able to run the filter stand alone. The file name will be in the ini file. ref:.linuxcnc.org/docs/html/gui/filter-programs.html

@endian, you may be interested to read the ethercat master docs Chapter 4, networking where it explains its interrupt-less network drivers that bypass all of the CPU affinity requirement...
etherlab.org/en_GB/ethercat

Also, ethercat has a number of specific NIC drivers but I seem to remember these are not included in the deb file in their repo and you need to compile from source to obtain them. It looks like they now support the Trixie 6.12 kernel. Driver Source etherlab.org/en_GB/ethercathttps://gitla...vices?ref_type=heads

drivers are loaded by ethercat.conf in place of ec_generic. It would be interesting to see if the  hm2_eth driver could be modified to use the ethercat drivers

That helps. I had seen the extra joints feature but didn't know enough about it to realize that is what I need.

Progress at this point:
I used Pncconf to create a common 3 axis mill config with the default mesa cards selected, as my mesa setup does not seem listed. I edited the generated mesa configs to:
1. Match my mesa hardware.
2. Converted the XYZ axis to simulated by zeroing their [JOINT]HOME_ ini parameters and connecting their pos_cmd to pos_fb.
3. Created 6 'extra joints' that I will actually be using.

I still have not figured out how to delete the axis gui without breaking a boatload of stuff. I begin to think I will be fine with allowing axis to load minimized, and have my gladevcp ui load maximized, and maybe also modal so it stays on top. It will be most convenient for the machine operator if my gladevcp never disappears from his touchscreen. I think he knows more about bending steel than I do about computers.

Are you seeing a difference between the target position (607A) and the actual position (6064) that is persistent? IE you can force the motor out of position a bit, and it returns to the same incorrect position?  This is different from following error, where the motor does not get to the position. With following error, if you force it, it will get to position and stay. OR if you force it past the target it will end with a following error from the opposite direction. 

One of the last problems to solve. I need to read from the current loaded file, to find some content. If this is possible from the imported testpy file, with a connected pushbutton.

 

Hello Rodw,

I’m also using the Plasmac post from SheetCam. I followed your advice and changed the SheetCam setting to output .ngc instead of .tap. Unfortunately, as long as the Monokrom filter is enabled, it doesn’t work—I get the error:

“unknown word where unary operation could be.”

This happens both on my actual machine and with the Monokrom simulation configuration. With QtPlasmaC, I don’t have any issues. Maybe over the weekend I can share a G-code test file that fails for me.

Is there a way to manually apply the Monokrom filter plasma_gcode_preprocessor to a G-code file outside of Monokrom, just to see what the output looks like?