Another plasma component...

I think I will change my instructions thread and suggest we use a custom post_plasmac.hal file. This file will include all of the customisation I have in plasmac.hal and it will be loaded by the .ini after plasmac.hal. That way on a new update, all you need to do is copy the sim folder to your live config folder and paste in your hal, ini and post_plasmac.hal file

Hi Rod

I already have a separate hal that was kindly put together for me by Islander John, so from that point of view an update does not bother my hal customisations as I would copy the updated plasmac.hal across with all the other files, and my custom.ini references both the plasmac hal and my custom one. In my question I was thinking mainly of my ini file as that is also a custom file.
For instance If an update changes something in the plasmac.ini, it is a manual process to integrate those changes to the custom ini file.
Not a major deal, I just wondered if I was missing something that would make life easier when updating.

Darren

Yes, a config only has one ini file so if Phill adds a new feature that changes the sim ini file, you would need to update yours (so keep it to a different name).
Re your other problems. Sounds like something is going wrong in the compile process. Follow the instructions I wrote and let me know how you get on. But:
1. Are you using a PREMPT_RT Kernel like the Stretch ISO?
2. Are you using mesa hardware or a parallel port?

My instructions were based on Mesa cards with their THCAD for voltage sensing so a PREEMPT_RT kernel is a prerequisite.

1 I am using Debian wheezy with RTAI
I am also using all Mesa hardware including thcad

I wasn’t aware the Mesa cards required preempt_rt?
My system runs perfectly on 2.7 with RTAI, I just have no thc configured.

Getting the thc working was the reason for moving to plasmac.

John,

From what I see when the plasmac.skip-ihs-type == 1 the skip distance is calculated from the start of the last cut. This way the origin for distance follows with each cut instead of being fixed at the last successful probe (the last place we know where the material surface is). Once you start this it is very possible to chain many small cuts for a long distance before probing again. It is very likely that you can be several cuts removed from the last probing location and still be within the IHS skip distance.

So, skip-ihs-type 1 should be skip IHS if within skip-ihs-distance of last successful probe location?

Sorry if I wasn't clear about what is needed here. If the logic is inverted then THC-enable and IHS skip type == 1 can mean work with THC (from end of cut) and == 0 no THC, work from last probe. If the logic is inverted then I don't need two signals from Gcode to control it only the THC-enable from Gcode.

I am not quite sure what you mean here.

Cheers, Phill.

Dee436 wrote:
1 I am using Debian wheezy with RTAI
I am also using all Mesa hardware including thcad

I wasn’t aware the Mesa cards required preempt_rt?
My system runs perfectly on 2.7 with RTAI, I just have no thc configured.

plasmac does run with RTAI, that is how I have been doing all my probe testing.

If you are using Mesa hardware then you will need PREEMPT_RT

Cheers, Phill