Advanced Search

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.

I put an old working backup of the ini and hal files just in case. Same outcome. The x and y encoders do read fine when moved by hand.

If you did not change anything in the hal/ini files, this points to a hardware failure of some kind.

Do the encoders still read the axis position if you move them by hand?

 

Hi,
I'm wondering if I'm missing something with, or if it's possible to change or add functionality to it.In previous systems using Heidenhain, I could specify which tool is in which pocket. This made it easy to swap out the entire tool carousel. I was hoping I could achieve something similar here—possibly by modifying thefile.I'm currently building a list of tools as follows:

• Tools 0–98: Standard tools
• Tool 99: Probe
• Tools 101–106: Separate pneumatic spindles

I've tried looking around for something that supports this kind of setup, but haven't found anything that matches what I'm trying to do. Any guidance or suggestions would be appreciated!

Thank you for the help. After looking into some more i just grapped a different pc.

Looks great! 
A new component for the logic, even the easiest way.
Btw, I noticed my hex to bin conversion was totally wrong, but you get the point with 7F and 0F.

Would G93 mode (inverse time) be better suited to your needs than the usual G94 units/min?
linuxcnc.org/docs/html/gcode/g-code.html#gcode:g93-g94-g95

Hi. Thanks for the help. It works now. It's not finished yet, but it's a good start.
Here are my files, maybe someone will like it.

​BR Pavel

Using the correct command:

halcmd: loadusr -Wn vfd hy_vfd -d /dev/ttyUSB1 -b 8 -p none -s1 -r 9600 -n vfd

worked.

Just having someone to bounce ideas off helps immensely.
Thank you Hakan

dmesg | grep ch341
[57931.173236] usbcore: registered new interface driver ch341
[57931.173797] usbserial: USB Serial support registered for ch341-uart
[57931.173820] ch341 7-1:1.0: ch341-uart converter detected
[57931.189484] usb 7-1: ch341-uart converter now attached to ttyUSB1

alcmd: loadrt -Wn vfd hy_vfd -d /dev/ttyUSB1 -b 8 -p none -s 1 -r 9600 -n vfd
Note: Using POSIX realtime
-Wn: dlopen: /usr/lib/linuxcnc/modules/-Wn.so: cannot open shared object file: No such file or directory
<stdin>:1: waitpid failed /usr/bin/rtapi_app -Wn
<stdin>:1: /usr/bin/rtapi_app exited without becoming ready
<stdin>:1: insmod for -Wn failed, returned -1
halcmd: quit
Note: Using POSIX realtime

Nope:

lsmod | grep ch341:

ch341 28672 0
usbserial 65536 2 cp210x,ch341
usbcore 348160 9 usbserial,ehci_pci,usbhid,cp210x,mt76_usb,ehci_hcd,ch341,uhci_hcd,mt7921u

looks like both have been loaded properly.

Those two are the most common devices. That should work.
Redo that "sudo dmesg" with the search for serial. Limit to the last say 10 line though,
that should give the port name. I just plugged in a random usb-serial device I had and got thisYou should hopefully get something similar and there is the device name: /dev/ttyUSB0