Advanced Search

Could StepGen be used to convert the absolute position data from the Fanuc encoder channels to quadrature pulses for outputting to encoder input on the drives? 

I have been using a very old Plasmac version from 2019 and although I alway planned to upgrade it, it just worked so got put off. A month or so ago I turned on my plasma only to find the hard drive had failed. I fitted a new ssd and did a build of QtPlasmac with Debian 12 bookworm. Although I got the machine working as such, I have a couple of issues that I am stuck on;

Using the same PC I used previously without issue, I now regularly get errors like 

“Mon24 13:59: Unexpected realtime delay on task 0 with period 1500000
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
Mon24 13:59: hm2/hm2_7i76e.0: Watchdog has bit! (set the .has-bit pin to False to resume)
Mon24 13:59: hm2/hm2_7i76e.0: Smart Serial port 0: DoIt not cleared from previous servo thread. Servo thread rate probably too fast. This message will not be repeated, but the hm2_7i76e.0.sserial.0.fault-count pin will indicate if this is happening frequently.”

I have tried the period setting at 1000000, 1500000, 2000000 etc latency test is around 35000. 



the other major issue is that I can’t cut anything that has an arc unless I use the QtPlasmac conversational. My sheetcam produced code just generates errors like

--- QtVCP Screen Started on: Mon, Feb 24 2025 13:12:29 ---
--- CNC_Plasma - QtPlasmaC v2.9-236.301, powered by QtVCP and LinuxCNC ---
Mon24 13:12: Tool 0: No Tool
Mon24 13:14: Loaded: /home/darren/linuxcnc/nc_files/examples/Darrens Gcode Files/Motor Moutn Blue Mill/10mm motor plate Arc Lead (SMM).ngc
Mon24 13:14: G-Code error in 10mm motor plate Arc Lead (SMM).ngc
Near line 42 of
/tmp/emcflt-m50pkakv.d/10mm motor plate Arc Lead (SMM).ngc
Radius to end of arc differs from radius to start: start=(X31.0695,Y19.2947) center=(X29.4735,Y20.3617) end=(X29.6980,Y20.4360) r1=1.9198 r2=0.2365 abs_err=1.683 rel_err=87.6824%

I have ensured G91.1 is active and all the holes entries are # out in the nc file. 

Can anyone point me in the right direction? I can provide any extra info needed


 

i am not sure whether this is a hal issue or an issue with qtdragon_hd.  
i have just installed 2.9 the newest build,
and rebuilt my machine.  on my old machine the esop on the screen and the physical estop worked independantly.  
now the estop on the screen only reflects the physical button.    may be this is the way it is ment to work and i just had somthing different. 
i liked it as i get the button on the oppiset side form the screen and i had an estop on both sides of the machine.
 

This is cool, I have Mesa CT making a working configuration for the 7i76EU now. Just need to add the spindle types.



Thanks PCW
JT

Update:
The machines works again, without unexpected real time delay and a very good latency, but i had to take the PC of my Lathe. (the lathe machine uses the Mesa 7i76e card)
That PC has a on-board graphic card, but i first tested it with the VGA that was already there and i got the same latency issues. As soon as i used the on-board vga, the latency was perfect and no "realtime errors" at start up.

I have started latency-histogram, with 4 x glxgears and a youtube video running for about 1 hour.
I first started the histogram, then opened one glxgears and waited to check if anything spikes happen. Then i opened 3 more glxgears. No latency spike. Then the youtube video and the pc was running like that for almost one hour without any change to the base thread.
On tomorrow i will run a milling program and check if anything bad happens.

Also i will connect that "latency issue PC" to the Lathe and hope there will be no problems, but i think with the Mesa card there shouldnt be any.

Perfect! Not sure what plasma cutter you have but if it was say hypertherm, a surface mount circular connector that just pushes into the socket on the machine and you would have a nice complete self mounting package. I used the 7i76e spindle relay for torch on so there is nothing wrong with your photo diode. You just need to add a pull down resistor on the arcOK as discussed in the qtplasmac docs. 

Of course if you had a XPR hi def its Ethercat anyway!

I want to set / reset a HAL pin by using G-codes (switching a pneumatic valve on/off).
In the documentation G-code Overview | 4. HAL pins and INI values is written: " ... the only way to set HAL pins from G-code remains M62-M65, M67, M68 and custom M100-M199 codes."
I wrote the below subroutine (macro):

   o<test> sub
   (MSG, Spannzange öffnen)
   M62 #<_hal[hm2_7i76e.0.7i76.0.0.output-00]
   o<test> endsub
   M2

When I run the macro, the response is: "Benannter Parameter nicht beendet"
(Using gmoccapy Ver 3.4.9 in German language)

Is there a better way to control HAL pins?
If not, what do I need to do?

Juergen
 

Fair enough. I thought I had gone through all the steps but I guess I missed it.

I just got a touch probe and want to set it up alongside my tool height setter.

Turns out the tool height setter I bought years ago is NC.
Without even thinking about checking I bought a NO probe which if I am thinking about it correctly if I wanted to wire them into the same pin it would have to be NO.

From what I can tell in reading though it seems like I should be able to wire them into separate pins on my 7i76e, distinguish one as NO, the other as NC, and get it to function properly correct?

And from reading it does sound like LinuxCNC still only has one probe function right? So in the configs I tie both sensors/pins to the single probe function correct?

The 7I76E has been replaced with the 7I76EU which is available from a couple of sources.
 
The 7I92T option would work with your existing breakouts, but it would require
completely different hal/ini files.

 

The T3D drive has an analog input option but no encoder output
(which is a bit uncommon) so will not work with the 7I97/7I97T.

A step/dir board would be required, a Mesa 7I96,7I96S or 7I76EU
are possibilities.

Yes, buying the 7i76e might be a good idea, but its difficult to get (out of stock everywhere) and i would wish to not need to rewire anything and configure.

Of course I could ask or look for a pc setup that works 100% with the newest rtai kernel and buy the same hardware, but its just strange that I cannot get that machine that worked really well with wheezy not working on debian 12.

On tomorrow i will try a couple more bios settings but all energy saving functions are disabled and I know I didn't had to fix so many things to get a jitter of about 8000.

@tommylight: this I have solved already and the machine sounds and works by jogging perfectly fine now, but I still get unexpected realtime error on task 1 on start up.

Currently I mostly do changes in the cpu ratio and other cpu settings like cpu bus frequency and if I setup a wrong value, lets say, cpu frequency 165 instead of 120 then the machine might make that strange movement, smooth but not all the time.

I attach 2 pictures of one windows screen (tweaker), so that you see the options. That are not anymore the current settings. Tomorrow I can show pictures of the other options available but I am sure it's setup correct.

In grub config I have only what was already there: "quiet" and I added "isolcpus=5" to it. I believe with wheezy I had isolcpus=1,2,34,5, but I am not sure anymore.
The cpu is a amd phenom ii x6 1055t.

Thanks for chiming in. I'm hopeful that this is not the solution I'm after. My goal is to convert these signals within LinuxCNC using something like the BLDC HAL component or something of that nature then spitting out the results via some of my available outputs on my Mesa cards. Surely Hopefully it can be done in HAL and not need an external converter board. These PICO boards would hurt the wallet too much as well, 600USD for 4 that's 850CAD and that's about half of my net worth

#machineShopOnAShoestring

I would recommend your 7i76e option you mentioned in your first post.

Wheezy is far too old to expect stuff to still work. its well past end of life
Whilst the linuxcnc guys have done an amazing job keeping RTAI working for all these years its also past end of life.
Without the Linuxcnc devs, RTAI would not exist today.
Preempt_RT has won the real time wars.
If the default Linuxcnc ISO works reliably for you, it will work with a 7i76e

But like any modern OS, things are more complicated today and there are a number of optimisations I cover here
docs.google.com/document/d/1jeV_4VKzVmOI...diY/edit?usp=sharing
 

Hello PCW,
I checked the hm2_7i76e.0.packet-error-total and got 57 errors about 45 minutes. Is this too much?

I don't understand these packet losses - (my PC is a lenovo ThinkCentre M92p Mini-PC, Intel Core i5-3470T 2.90 GHz 8GB Ram, in the latency Test I get readings as shown in the photos, first at start, Servo 4000, Base 5608, after 30 minutes surfing, coding in Vcode, doing sth else: servo 82040, Base 24542, I set servo thread in the INI file to 1.600.000.
Kernel release 6.1.0-29-rt-amd64, Kernel Version #1 SMP PREEMPT_RT Debian 6.1.123-1 (2025-01-02)
What do you think?

I did the most Latency tips in this thread: forum.linuxcnc.org/38-general-linuxcnc-q...ead-and-irq-affinity - I disabled hyperthreading, power saving, virtualisation, TPM, turbo mode, ACPI, APM, Audio,, kernel isolate core 0 for interrupts - quiet irqaffinity=0 isolcpus=0. I bought a new network controller with RTL_8125 chip,  optimize my network connection with sudo ethtool -C eno1 rx-usecs 0 at any system start. Kernel release 6.1.0-29-rt-amd64, Kernel Version #1 SMP PREEMPT_RT Debian 6.1.123-1 (2025-01-02)

Anyways, I dont have servo motors with encoders wired to the MEsa 7i76e, so I cannot calibrate in live mode. I just set the FF2 to 0.0003 as you said. Same results as yesterday, not often but sometimes i get that motor-0-position errors.
Maybe my PC is too slow for a Linux system? Any suggestions?
Thank you so much for your support!
Hanno
(For some reason, I cannot put photos <1MB in this thread...)

The 7I76EU (and 7I76U) have 3 new parameters and the 7I84U has 2 new parameters

The main 2 added parameters are 7i76.[port].[chan].output_source and 7i76.[port].[chan].output_sink. or
7i84.[port].[chan].output_source and 7I84.[port].[chan].output_sink. These are 16 bit masks
that control the field output mode. Each xxxx.output_source  bit controls the source attribute
of the corresponding output bit and each xxxx.output_sink bit controls the sink attribute. The
default setting is for all source mode (xxxx.output_source = 65535 or 0xFFFF, xxxx.output_sink
= 0 or 0x0000) which means a 7I76EU, 7I76U or 7I84U behave like a 7I76E,7I76 or 7I84.

So for example:

xxxx.output_sink = 0 = 0x0000
xxxx.output_source = 65535 =0xFFFF
 = normal all sourcing mode (like 7I76E, 7I76,7I84, this is the default)

xxxx.output_sink = 65536 =0xFFFF
xxxx.output_source = 0 = 0x0000
 =  all sinking mode  (like 7I76ED,7I76D,7I84D)

xxxx.output_sink = 65280 =0xFF00
xxxx.output_source = 255 = 0x00FF
= outputs 0..7 are sourcing mode, outputs 8..15 are sinking mode

xxxx.output_sink = 65535 =0xFFFF
xxxx.output_source = 65535 = 0xFFFF
= all outputs are in push-pull mode

Note that each of the 16 output bits can be individually setup for
sourcing, sinking, or push-pull mode.

The 7I76EU and 7I76U also have a spinmode parameter to set the spindle output
bit mode when this is 0 (default) the isolated spindle output bits are ENA and DIR as before.
If the spindle mode bit is set to 1 , the isolated spindle output bits now function
as FWD and REV.