Advanced Search

Hi all!

first of all, great work! I managed to get everything running just by reading all the great posts here! All the nice HowTo´s and so on... 

But now i got stuck...

what do i have?

i´m running a RPi 5 with LinuxCNC (latest Preempt Version) 
a Mesa 7i76EU (everything working)
a Pendant WHB04-6 (everything working)
and some Beckhoff EtherCat modules (everything working)
and last i got my self an EtherCat Module for the Omron MX2 (partial working)

I can´t figure out how to drive the Omron MX2, there is some mismatch in the type of the controlword
my ethercat xml has only the Modulelist, no special entries like syncmaster and so on... 

the Device shows up in the HalShow under lcec, all "Pins" are viseble, ethercat slaves shows the device... so i think its just a small config problem in the xml

maybe someone out here who has it running...

Thanks for looking / helping...

Cheers Einar 

 

PCW wrote:

I would think that could be done with 2 mux2 components
(1 for X and 1 for Z) that select between anglejog outputs
when anglejog is enabled and direct MPG counts when
anglejog is not selected.

Agreed I will need two, one for X and one for Z, however mux2 works with floating point numbers, and the MPG counts are S32, so I don't think I can use mux2

mux_generic seems like it should work because you can select the data type, however I need a little help configuring mux_generic:
  - I assume I would add it to the servo-thread?   loadrt mux_generic config="??????"
  - the other pins are a bit fuzzy, looks like I need to specify:
     mux-gen.00.in-s32
     mux-gen.00.out-s32
    
I'm not sure how to:
a)  assign encoder-counts and angle_x to the two inputs of the multiplexer?
b)  route the output of the multiplexer to axis.x.jog-counts?
c)  define the control bit that will select the desired input? 

   Your help is appreciated.

So both motors are triggered and do move (jolt) when I enable the machine in linuxcnc. Looks like a central command goes to both motors to move. Powering the esab machine without linuxcnc is fine. No movement. Will check the voltage and report back.

Overrides are just set via physical up and down buttons, or via GUI in my setup.

New machine will sue encoders to have physical knob.

If easiest, a pop up warning that overrides are set, and buttons to cancel program, or proceed, would be very useful.

"I would greatly appreciate it if you could replace QPlainTextEdit with QsciScintilla."

"Reset to 100%" would not work if you are using analog signals for the overrides.
So it will be only options for proceed and abort.

Dude, your machines look awesome by the way! 

there is only one RAM module in the PC, but i tried to swap it with a module from another PC. Both module have different speeds, sizes and manufactors. The same is for a second graphics card i tried.

But again without luck.

Wish i had another Ryzen CPU for testing but i haven't.

I’ve just discovered that the Mesa Configuration Tool (at least the version available prior to 8/19/2024) does not configure the manual tool change section correctly.  I recently discovered this when my file did not stop at the M6 command and continued on to the next set of code.  I was able to look at a .hal file set up with pncconfig and copy the manual tool change section from there and now everything works correctly (I get the manual tool change pop up window when the M6 command is encountered). This is a Mill setup that uses the AXIS GUI.

Here are the two configurations:

Pncconfig version that works:

#  ---manual tool change signals---
net tool-change-request    <= iocontrol.0.tool-change
net tool-change-confirmed  => iocontrol.0.tool-changed
net tool-number            <= iocontrol.0.tool-prep-number 

#  ---Use external manual tool change dialog---
loadusr -W hal_manualtoolchange
net tool-change-request    =>  hal_manualtoolchange.change
net tool-change-confirmed  <=  hal_manualtoolchange.changed
net tool-number            =>  hal_manualtoolchange.number

#  ---ignore tool prepare requests---
net tool-prepare-loopback   iocontrol.0.tool-prepare      =>  iocontrol.0.tool-prepared


Mesa Configuration Tool version that doesn’t invoke the manual tool change pop-up or pause the code at M6:

#  Manual Tool Change Dialog
loadusr -W hal_manualtoolchange
net tool-change-request    =>  hal_manualtoolchange.change
net tool-change-confirmed  <=  hal_manualtoolchange.changed
net tool-number            =>  hal_manualtoolchange.number

# create signals for tool loading loopback
net tool-prep-loop iocontrol.0.tool-prepare => iocontrol.0.tool-prepared
net tool-change-loop iocontrol.0.tool-change => iocontrol.0.tool-changed

 Regards,

Skylor

Interface between ARM-Core and FPGA-Part works, using AXI.

next step: udp2axi program for the ARM-Core

I would think that could be done with 2 mux2 components
(1 for X and 1 for Z) that select between anglejog outputs
when anglejog is enabled and direct MPG counts when
anglejog is not selected.

I didn't know about g93 you're right that's definitely the way to go

PCW wrote:

Normally the MPG encoder count goes to all Axis jog count pins,
so no routing of the counts is needed.

This is required so that LinuxCNC can track the current MPG count
and only apply changes to the enabled axis.
 
 

The problem is that when using anglejog for emulated compound movement (X+Z), the MPG ticks get processed by anglejog and then analogjog outputs the sin and cos values that are to be fed to; axis.x.jog-counts, and axis.z.jog-counts, however in HAL,  axis.x.jog-counts, and axis.z.jog-counts are already being driven by the raw (non sin and cos values) from the MPG for non compound/anglejog use.

axis.x.jog-counts, and axis.z.jog-counts, can't be driven by both the MPG and anglejog

net encoder-counts  <= hm2_7i96s.0.inm.00.enc1-count
net encoder-counts => axis.x.jog-counts
net encoder-counts => axis.z.jog-counts
net encoder-counts => anglejog.counts-in
net angle_x <= anglejog.coscounts
###net angle_x => axis.x.jog-counts  can't do this!!!
net angle_z <= anglejog.sincounts
###net angle_z => axis.z.jog-counts  can't do this!!!


 

I guess the next step would be to make sure that the analog output path is OK.

A quick check would be to make sure that the analog output voltage of the 7I77
is near 0V when LinuxCNC is not running.

Normally the MPG encoder count goes to all Axis jog count pins,
so no routing of the counts is needed.

This is required so that LinuxCNC can track the current MPG count
and only apply changes to the enabled axis.
 

"mistakenly called an operating system"