Advanced Search

"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"

I think the card needs to be installed during the installation.

That way, its kernel module will be loaded during boot-up.
 

You're wrong, so very very wrong.
 

OK, that only leaves the memory modules, so if there are two, try yanking one out and testing, then the other one and test again.
-
Explanation for some of my replies:
I use a lot of Ryzen PC's, including this one i am typing on:
forum.linuxcnc.org/show-your-stuff/55173...thers-company#331546
And the rest on that topic, one thing i found out the hard way is that PCI-E issues will sometimes show as memory errors on Linux boot and DMESG, and easy to reproduce by using different GEN devices, mostly graphic cards, especially if using riser cable for it.

No RGB for now, but soon, and putting that tempered glass on!

PCW wrote:

Typically this is done by by connecting the MPG count to all axis
and selectively enabling jogging on the desired axis
 

Thanks for that. I'm almost there.....

I have two rotary switches, each switch has 2 outputs driving inputs on a MESA card as 00,01,10,11

Switch #1 is used to select MPG increment 0, 0.0001", 0.001", 0.01"  I'm using a MUX4 to control that. No problem with this.

Switch#2 is for selection of where the MPG ticks   ( net encoder-counts  <= hm2_7i96s.0.inm.00.enc1-count ),gets routed, so to either:
X, Z, C (Compound), or N(None), so....
axis.x.jog-counts
axis.z.jog-counts
anglejog.counts-in
or to nowhere when position N is selected

I now have the rotary switch working for: none, X or Z by simply enabling jogging for X or Z as required. For Compound action I can simply enable both X and Z when in compound mode.

Final hurdle is that I have two S32 source signals:
   1) The MPG signal called (encoder-counts), for non-compound moves. Configured and working as net encoder-counts => axis.x.jog-counts
   2) The modified by anglejog MPG signal for compound moves called (angle_x). I can't simply configure as net angle-x => axis.x.jog-counts

 HAL does not allow two sources to drive one output pin. I'm guessing that mux_generic might be the best solution, to allow choosing the source signal for axis.x.jog-counts?

Assuming mux_generic is the best solution, 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.