Advanced Search

the only thing I could see was  36 bit IN FALSE plasmac.thc-auto <== plasmac:thc-auto
I would have thought you would have this true in the GUI. Does it change the pin if you do change the gui setting?
plasmac:thc-auto should be set in a system file though

after checking I in fact had the mode set to zero when should have been set to one, must have messed with it when I was testing, changing it to the correct mode did not affect the problem


the torch is performing touch off and arc start correctly, just the thc after not activating


I did run the codes to create the txt files but dont know how to do the manual cut and run the halcm at the same time, so thc wasnt active then, cant see anything different in the files but i dont really know what im looking at
both files below

Hi,
Thank you so much for the quick fix on the touchy prefix and for explaining the call_list mechanism! That makes managing external custom files much cleaner. Also, the virtual signals logic feature looks very neat and powerful—I'll definitely look into the demo.
Regarding signal assignment in Rio Flow: while having auto-detection via POSTGUI_COMPONENTS works great for standard prefixes, would it be possible to add an explicit target selector in the UI (for example, a dropdown or toggle in the HAL-Signals section to choose whether a connection belongs to Main/PreGUI or PostGUI)?
Having this option directly in the GUI would give maximum flexibility:

• It prevents having to hardcode every possible GUI/component prefix inside POSTGUI_COMPONENTS.
• It handles custom user interfaces, custom PyVCP/GladeVCP panels, or non-standard naming schemes seamlessly.
• It allows users to decide explicitly where each net lives directly from the Rio Flow design environment.

Thanks again for the great support and active development!

Hi Oxbown,
thanks

you can add your own .hal files to the call_list's:

$ cat Output/Tangbob/LinuxCNC/pregui_call_list.hal
source my_own_pregui.hal

$ cat Output/Tangbob/LinuxCNC/postgui_call_list.hal
source custom_postgui.hal
source my_own_postgui.hal

these extra source entries are not removed during generation


i add the 'touchy' prefix to POSTGUI_COMPONENTS (riocore/generator/hal.py),
now, all generated HAL entries beginning with ‘touchy’ should end up in the PostGUI HAL (in main and dev branch / git pull)

Unfortunately, I haven’t used ClassicLadder yet, so I can’t be much help there,
but it’s a good opportunity to mention a specific feature in Rio again

When specifying a signal source, you can use various logic and functions.



I think it’s a killer feature that doesn’t get nearly enough attention

you can start a demo configuration:
```
rio-generator -S riocore/configs/haldemo/virtual-signals-axis-pyvcp.json
```

Hi everyone,
First off, huge thanks to the @meister for the amazing work on RioCore and Rio Flow. It makes FPGA-based configurations for LinuxCNC much more accessible and structured!
I’m currently setting up a machine using RioCore with a Touchy interface and a physical control panel (hardware buttons, safety relays, etc.), and I have a couple of architectural questions regarding custom HAL management:
1. Loading Custom Real-Time Components in Main HAL (e.g., ClassicLadder)
Is there an intended workflow or plans to allow custom HAL code injection inside Rio Flow?

• Use Case: I need to load and thread ClassicLadder (

  loadrt classicladder_rt ...

  , 

  loadusr -w classicladder my_logic.clp

  ) to handle auxiliary machine logic and map FPGA inputs/outputs directly to 

  %I

   and 

  %Q

   points before the motion thread starts.
• Currently, modifying generated main HAL files requires re-editing them after each export. Would it be possible to have a persistent "User HAL Block" or a dedicated non-destructive include file in Rio Flow?

2. Managing Custom PostGUI Nets Without Being Overwritten
How should we best handle GUI-dependent nets across exports?

• Use Case: Connecting physical hardware inputs mapped in RioCore to GUI-specific pins like 

  touchy.cycle-start

  , 

  touchy.single-block

  , or 

  halui.machine.on

  .
• Since these pins only instantiate after the display loads, they must live in the PostGUI phase. However, each time Rio Flow regenerates/exports the setup, the auto-generated PostGUI call chain (

  postgui_call_list.hal

   / 

  custom_postgui.hal

  ) gets wiped/reset.

Is there a recommended way to structure user-defined pre-GUI and post-GUI files so Rio Flow leaves them untouched, or is native support for custom code injection / user PostGUI nets planned for future releases?
Thanks in advance for any insights or tips on how you guys are handling this!

Is it performing the touch-off and arc lighting when you start the program? Torch goes down, contacts the plate (depending on your touch-off sensor), goes back up to striking height, lights the arc, at which point the THC can start reading arc voltage. Is it doing any of that?

Sorry I missed the analog stuff in the hal file.

One thing you might do is (with LinuxCNC running)

1. Without gcode running:

halcmd show pin plasmac  > nogcode.txt

2. With gcode running:

halcmd show pin plasmac  > gcode.txt

and then compare the two files.


 

If a lot of your outputs are related to some sort of logic that "just needs to run in a background program" you can control any or all of them using a custom hal component. There is also classicladder plc logic in LinuxCNC.

have you chosen the correct mode in plasmac? refer docs

How do you want to command your outputs? There are a myriad of ways to control them with in Linuxcnc, custom M-codes being just one. In fact you could command up to 32 outputs with just a single custom M-code with the addition of a binary variable (M100 Pn) where n= an integer number that is written to a hal pin (Bitslice Hal component) who's binary value sets the value of each output pin. You could add another 32 by adding a Q variable to the M-code for a total of 64 outputs with a single M-code command. Now remembering all of your possible binary integer commands to turn on/off the correct outputs might be a bit of a trick, but that shouldn't be hard for a computer to do. I've done this before myself, but for only about 16 outputs.

I looked at the code I was using and the thc enable gcode is there, the thc enabled light is on, but not the thc active light thats what confuses me, what are the requirements for it to activate?

What does your G-code for the above move look like? The answer might be as simple as adding another line of code, or moving the line where the G41/42 is issued.

voltages sound about right. Nice to know ethercat is so simple to install for plasma machines.

I'm a bit rusty, it can be a bit cantankerous  on non standard setups, Check the thc is not disabled in the gcode which sounds a likely place to look

You could use ethercat. Start with a EK1100 coupler
www.beckhoff.com/en-en/products/i-o/ethe...-coupler/ek1100.html
and then add 32 output EL2407 modules as required.
www.beckhoff.com/en-en/products/i-o/ethe...l-output/el2407.html
6 would give you 192 outputs and an  EL2008 rounds it off to exactly 200 inputs.
the EK1100 can supply for 2 amps but the power bus is can handle 10 amps. If you need more power you can insert a EL9410 power supply module between modules on the bus.
www.beckhoff.com/en-au/products/i-o/ethe...x-system/el9410.html

 

Im using a beckhoff 3102 +-10v analog input so im dividing the arc voltage 30:1 inside the powermax 65, and after the first tests with a bench power supply I realized that the beckhoff module outputs a float value between -1 and +1, given the range I assumed it relates the voltage and the float output value 10:1, so in qtplasmac i combined the two ratios to be 300:1 the cut voltage appears to display right in the tests i have done so far, 200 something volts at ark start and stabilizing at about 130V and that agrees with hyperterm's tables for the parameters im using

edit:
and as I said before thc is working fine when doing a manual cut with the jog keys