Advanced Search

Its really important to read the instructions for the version of LInuxcnc you are using. Often a Google search will display dated info

Instead of rapid.rapid-override, it should be rapid-override.

What manual is this in and what LinuxCNC verison?

(the current halui man page does not have this error)

how about these instructions?
github.com/LinuxCNC/linuxcnc/blob/2.9/li.../designer/README.txt

Thanks for that.

With a bit of fiddling I have some code that is doing the job....
My halui was set up like this

[HALUI]
# add halui MDI commands here (max 64)
MDI_COMMAND = O<b01-go_to_switches> call
MDI_COMMAND = O<b02-go_to_wco> call
MDI_COMMAND = G10 L20 P0 X0 # zero x axis
MDI_COMMAND = G10 L20 P0 Y0 # zero y axis
MDI_COMMAND = G10 L20 P0 Z0 # zero z axis

and the code for the buttons ended up looking like this...

#

---

# Buttons to zero the axis of the machine.
#

---

addf AND-zero-x servo-thread
addf AND-zero-y servo-thread
addf AND-zero-z servo-thread

net zero-button <= input.0.btn-base3 => AND-zero-x.in0 => AND-zero-y.in0 => AND-zero-z.in0
net x-btn <= AND-zero-x.in1 <= input.0.btn-trigger
net y-btn <= AND-zero-y.in1 <= input.0.btn-thumb
net z-btn <= AND-zero-z.in1 <= input.0.btn-base

net zero-x <= AND-zero-x.out => halui.mdi-command-02
net zero-y <= AND-zero-y.out => halui.mdi-command-03
net zero-z <= AND-zero-z.out => halui.mdi-command-04

I'll post the files for anyone who is interested.

Thanks
Alex
 

Another mystery solved: My 7i54 pwm output to the proportional valve was extremely erratic, like all over its output range. I was ready to blame RFI/EMI interference problems, except only that channel was affected, everything else is very stable. I finally traced it to the snubber circuit on the solenoid coil. I removed that, then it worked fine. Now I have the ram jogging up and down open loop. It appears this rc snubber was messing with the current regulation. Attached a picture of it. It was sandwiched between the connector on the solenoid coil and the Hirschman plug. With that installed, its LED indicator flickered like a candle flame in a breeze whenever pwm output was live. The Ursviken schematics indicate the circuit contains a flyback diode, but I could not find any, neither does it seem to show up when I reverse the h-bridge. The snubber is unnecessary in this instance, I am powering it with an h-bridge designed for DC servo motors. A DC servo motor would not have this additional snubber anyway.

My suspicion has been confirmed: The 2 servo valves set the speed and direction of each ram cylinder. The proportional relief valve sets the tonnage. 0% pwm = no pressure, 100% pwm = max pressure.

I will edit my first post with this info. Once I have a complete working config, that will also be attached to the first post.

What inaccuracies? In the documentation?

I conducted a large series of experiments with different sensor settings and different ini + hal settings.
First, I achieved smooth operation of the sensor (of my own design) in version 2.8.4. The Chinese sensor could perform 40,000-50,000 continuous measurements (with 38.5 disabled). My sensor completed the entire task, more than 500,000.
That is, it has been established that the quality of the sensor directly affects the appearance of the error “Probe tripped during non-probe move”.
And with the same settings in version 2.9.7, the error “Queue is not empty after probing” recurs. That is, the appearance of the error does not depend on the sensor. The question remained: does this error appear during the working stroke 38.2-38.3 and the reverse?
I disabled the “until open” movement option, as in version 2.8.4, and the error “Queue is not empty after probing” did not appear. Previously, it was not possible to obtain more than 25,000 measurements. The experiment was interrupted at 40,000. Consequently, the error “Queue is not empty after probing” occurs when executing g38.5, during execution. After g38.3, I have a G1 up command.

To disable the possibility of 38.4-38.5 on the defunct Russian forum (к сожалению, я не помню имени автора решения, но честь ему и хвала), such a modification of hal was proposed and tested by me over hundreds of hours of work and hundreds of thousands of measurements -

Yes, I thought you wanted to use it in linuxcnc. That's how.
I'll tell you about dc synchronization tomorrow. It's a bit more writing and more code.
 

 
I don't think you want to use the Mux4 component. It is for setting an output to one of 4 numeric values. I think you would want to use multiple And2 components. Also you have the the Halui MDI Hal pin names wrong. To call the first Halui MDI command in your INI file's list the Hal pin name should be "halui.mdi-command-00" and the 2nd would be "halui.mdi-command-01"...

To do it you'd need to put the following lines in your hal file.  Assuming your button output pin names are "input.0.btn" for the zero button, "input.x.btn" for the X button, "input.y.btn" for the Y button, and "input.z.btn" for the Z button.  And since your INI file already has 6 Halui MDI commands listed, adding 3 more to zero each axis would be.
That said, if you are wanting to use a button input that is already used elsewhere in your hal file that is ok.  Simply either use that hal signal name to connect the appropriate and2.N.in1 to it, or add the and2.N.in1 to the existing net line.
 

It's already working in free run mode, I can see my encoder value in twincat such as in your 3rd video

ethercat-conf.xml

You mean the linuxcnc file? 

Are you using a MOSFET to heat the wire from the SKR? If so, I suggest reducing the PWM duty cycle and seeing what happens. First of all, try connecting the resistance wire directly to the power supply — reminder: this might help — and check whether the “Bad SPI Payload” messages still occur. You may also want to consider powering the resistance wire from a completely separate power source.

I was very close to replacing the Linux CNC with a different system.
The small inaccuracies make it very difficult for a newcomer.

I've spent several hours trying to get rapid override working. I happened to read about the change in the designation from MVO to RO. The Mesa Config program doesn't recognize this yet.
Then I noticed that the manual has the wrong name.
Instead of rapid.rapid-override, it should be rapid-override.
I have now entered the following manually and it finally seems to be working.

# ---max Geschwindigkeit Neufestsetzungs-Signale an Mesa Encoder - mpg (rapid override signals to mesa encoder - mpg)---

net ro-count     <=  [HMOT](CARD0).7i73.0.0.enc3.count

# verbinde max Geschwindigkeit Neufestetzung Inkrement - MPG (connect rapid override increments - MPG)

    setp halui.rapid-override.direct-value false
    setp halui.rapid-override.scale 0.01
    setp halui.rapid-override.count-enable true
net ro-count            =>  halui.rapid-override.counts

That did it. I didn't specify a subindex, since the drive manual said there isn't one for 0x607C. However, at least in this case, ethercat download doesn't work without it.

'ethercat download -p2 -t int32 0x607C 0 35951' works as expected.

Before I had a serious accident with a mouse that resulted in a 3.5 tonne Shizuoka mill turning up at the house, I converted my Bridgeport clone to CNC using a Chinese all-in-one controller from Newker. Those things in the photos are for the z axis drive, housing the closed loop stepper, timing belt drive and pulleys. I fitted a 16mm ballscrew where the original feed trip adjuster screw used to live, as this is much neater and robust than the usual arrangement with a ballscrew cantilevered in front of the head and required minimal modifications to the head. The top one is the final iteration.
Here's a picture of the basic mechanism, before the limit switches, encoder scale etc were fitted (otherwise you wouldn't see the ballscrew).
 
You inevitably lose some of the precious z axis travel due to the limit switches etc but I managed to minimise that and retain most of the 5" motion.