Torch Breakaway and Torch Pulse

rodw wrote: I think the lead developer is lucky bugs are reported here on on the issues register. I'm sure the official view is that the LD is a gun programmer cos there is never any issues reported on his code ......

Official issues register or not, to believe anything but that would just be ... crazy..

rodw wrote: I think the lead developer is lucky bugs are reported here on on the issues register. I'm sure the official view is that the LD is a gun programmer cos there is never any issues reported on his code ......

HaHa, yeah, you have to play your cards right.

NOTE: PlasmaC now uses the motion.motion-type HAL pin. If your configuration already uses this you will need to do some HAL editing.

*raises hand* I'm that guy... and Rod will be, and whoever else uses the ohmic2.comp

So, I tried:
and I get an error that says:
And it occurs to me that I still don't understand HAL, despite poking until it works, which I could not do this time. Any help would be appreciated. Basically Rod uses that in his ohmic2.comp "net ohmic:type <= motion.motion-type".

Thanks as always!

I did look at what I could find on the ohmic component but didn't see that pin being used, I didn't realise there were two models.

You shouldn't need to or it, just net the plasmac:motion-type signal to the ohmic.motion-type pin

phillc54 wrote: I did look at what I could find on the ohmic component but didn't see that pin being used, I didn't realise there were two models.

You shouldn't need to or it, just net the plasmac:motion-type signal to the ohmic.motion-type pin

Yea, it's a bit messy at the moment, Rod started a ohmic2.comp when we were having the water in the torch issues. He uses the aforementioned pin to turn the ohmic relay on and stay on the entire time a program is executing.

So just?:

A few other things I noticed (I've been busy after work haha):
1. Should there be an error associated with trying to pulse the torch and either the float switch or the breakaway (or both) is tripped? It might alleviate some inquiries here at a later date?

2. [strike]I noticed the folder structure changed. I was a bit confused because my table was named "plasmac" (a stupid idea in retrospect). Are there any ill effects of having the machine name match the new naming convention? One thing that is confusing is I now have 2 plasmac folders (one in linuxcnc\configs and one in linuxcnc\configs\plasmac). Another thing is that within the second plasmac folder, there is a plasmac.hal which appears to be a dummy .hal file for dummies like me :lol:. Maybe it might be prudent to put a note in the user guide to advise naming it ANYTHING but "plasmac" :silly: Sometimes I cant get out of my own way haha. It's like these things just find me lol[/strike] EDIT: It was named "plasma", long day. I can read I swear.

3. It looks like in the user guide that some "<machine_name>" references are missing the ">" (they read "<machine_name" currently in the manual).

4. Last one, I think. I noticed that pictures are back in the devel (master) version of the user guide. How did you fix that?!

What Phill says.

where you are coming unstuck is that motion.motion-type is an output pin and part of the LCNC core.
It is connected to the plasmac.motion-type pin (at a guess)
Phill already has a signal now for motion.motion-type so that signal can be reused to connect to ohmic2.
If you wanted to totally change what the plasmac pin did you would use unlinkp plasmac.motion-type
A signal (thiunk a wire) can be hooked to many pins but you can't connect multiple signals to one pin.

Yes, ohmic2.comp was a work in progress to fix some of the issues with ohmic.comp on water tables but its not final as I had some issues afterwards and I need my table back together to test it works properly...

Once that is done, I 'll be leaning on the LD to add some adjustment capability in the Plasmac GUI .....
Its the kinda thing that may change from job to job. eg Ally might be different from steel.

rodw wrote:
Yes, ohmic2.comp was a work in progress to fix some of the issues with ohmic.comp on water tables but its not final as I had some issues afterwards and I need my table back together to test it works properly...

Once that is done, I 'll be leaning on the LD to add some adjustment capability in the Plasmac GUI .....
Its the kinda thing that may change from job to job. eg Ally might be different from steel.

In all honesty, I havent had any issues with ohmic2 yet. It works fine, so long as I give it a good path to ground.

But when you are ready for more testing, I'll find a way to break it :laugh:

snowgoer540 wrote:

phillc54 wrote: I did look at what I could find on the ohmic component but didn't see that pin being used, I didn't realise there were two models.

You shouldn't need to or it, just net the plasmac:motion-type signal to the ohmic.motion-type pin

Yea, it's a bit messy at the moment, Rod started a ohmic2.comp when we were having the water in the torch issues. He uses the aforementioned pin to turn the ohmic relay on and stay on the entire time a program is executing.

So just?:

Code:

net ohmic:type => plasmac:motion-type

comment out your existing motion-type stuffs then:

1. Should there be an error associated with trying to pulse the torch and either the float switch or the breakaway (or both) is tripped? It might alleviate some inquiries here at a later date?

Dunno, see what others think.

2. I noticed the folder structure changed. I was a bit confused because my table was named "plasmac" (a stupid idea in retrospect). Are there any ill effects of having the machine name match the new naming convention? One thing that is confusing is I now have 2 plasmac folders (one in linuxcnc\configs and one in linuxcnc\configs\plasmac). Another thing is that within the second plasmac folder, there is a plasmac.hal which appears to be a dummy .hal file for dummies like me :lol:. Maybe it might be prudent to put a note in the user guide to advise naming it ANYTHING but "plasmac" :silly: Sometimes I cant get out of my own way haha. It's like these things just find me lol

Should be no issues with the directory structure. I redid it to keep the users config directory looking a lot cleaner. The palsma.hal file is required so that old configs can still load and update. I did note that in the file itself.

3. It looks like in the user guide that some "<machine_name>" references are missing the ">" (they read "<machine_name" currently in the manual).

Thanks, my editing and proof reading is getting worse, want another job?

4. Last one, I think. I noticed that pictures are back in the devel (master) version of the user guide. How did you fix that?!

jepler fixed that.:
github.com/LinuxCNC/linuxcnc/issues/860
github.com/LinuxCNC/linuxcnc/pull/901

phillc54 wrote:

snowgoer540 wrote: 1. Should there be an error associated with trying to pulse the torch and either the float switch or the breakaway (or both) is tripped? It might alleviate some inquiries here at a later date?

Dunno, see what others think.

That seems reasonable.

phillc54 wrote: comment out your existing motion-type stuffs then:

Code:

net plasmac:motion-type => ohmic.motion-type

That didnt work, it says "Pin ohmic.motion-type does not exist" I attached my connections hal because I'm dense.

Thanks, my editing and proof reading is getting worse, want another job?

Always happy to help!