Advanced Search

Hi i'm trying to open a sim config on 12 inch monitor with 1024x768 at 4:3 but gmoccapy gives and error with every sim config.
I tried even the 800x600 but the same error.
I tried axis and it works but the windows is bigger than the display.
The system is debian 12 si linux cnc 2.9.3 and rtai kernel 5.4.258
btw why the forum gives me and error when i try to put the code ?(You have too many links in your message, please decrease them! )
I uploaded the error code.
 

I will also need to build a specific file for linuxcnc to recognize the board right? Is there any documentation about this?

To connect encoders, the following pins are exported:

gmoccapy.jog.jog-velocity.counts (s32 IN) - Jog velocity

gmoccapy.jog.jog-velocity.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.feed.feed-override.counts (s32 IN) - feed override

gmoccapy.feed.feed-override.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.feed.reset-feed-override (bit IN) - reset the feed override to *0%

gmoccapy.spindle.spindle-override.counts (s32 IN) - spindle override

gmoccapy.spindle.spindle-override.count-enable (bit IN) - Must be True, to enable counts

gmoccapy.spindle.reset-spindle-override (bit IN) - reset the spindle override to *0%

gmoccapy.rapid.rapid-override.counts (s32 IN) - Maximal Velocity of the *chine

gmoccapy.rapid.rapid-override.count-enable (bit IN) - Must be True, to enable counts

linuxcnc.org/docs/html/gui/gmoccapy.html

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.