- Posts: 757
- Thank you received: 216
Another plasma component...
- islander261
- Offline
- Platinum Member
-
Less
More
7 years 6 months ago #130911
by islander261
Replied by islander261 on topic Another plasma component...
Do you have working .ini and .hal files that move your mechanics correctly? If so post them.
I will give complete instructions later when I am finished with the days work.
John
I will give complete instructions later when I am finished with the days work.
John
Please Log in or Create an account to join the conversation.
- Grotius
- Offline
- Platinum Member
-
Less
More
- Posts: 2419
- Thank you received: 2349
7 years 6 months ago - 7 years 6 months ago #130916
by Grotius
Replied by Grotius on topic Another plasma component...
The dry run is very important to have. @Zultan..Glenn..
I solved this by the following, important for phil who is currently writing a new plasma component :
In my component i made a arc-ok fake button.
So the dry run is simply running when the arc-oke fake button is on.
( the plasma component is alway's looking for the arc-oke signal when active. ( programmer's logic )
When the arc-oke is incoming, the machine is allowed to move. (smart connected halui.pause connection).
When you want to dry run and have no arc okey signal, the component will say, we will not move !!!!
So the student can not dry run, what is a shame for us. But it will be solved soon. In the previous provided ethercat component, it's available as a fake button. That you cannot see because the gui interface is not provided. Only the connections are provided.
I remember posting my experience with linuxplasma so far in post at this post :
: forum.linuxcnc.org/plasma-laser/35449-an...ent?start=230#130217
Keep in mind. This is the most powerfull linux plasma application currenty in use.
In the next post Phill will have a look at my files.
But i know it's hard to follow. C code can be very confusing, and i mentioned that my component names (logical names)had to be more specialised trough the testing periode.
In the attachment of the above post, look at the signal pin in bit arc_ok_togglebutton "";
If the arc_ok togglebutton is active, in c code it goes to a separate code section called "case togglebutton" or when not active it's case is "case no_togglebutton". But in plasma world. It's very difficult to write a good component. Testing of component's are in my case alway's done on real machine's and the time it takes include testing is sometimes 2 day's or more when i start from scratch.
(remember i have a different linuxcnc distribution. My component works on a exernal offset branche cruisifide with a reverse run branche).
I can see my current offset in Z dro. I can see my actual tool path (how the thc is responding path) etc. It is still the mach3 killer in all way's. But you have to know how to install it.
I solved this by the following, important for phil who is currently writing a new plasma component :
In my component i made a arc-ok fake button.
So the dry run is simply running when the arc-oke fake button is on.
( the plasma component is alway's looking for the arc-oke signal when active. ( programmer's logic )
When the arc-oke is incoming, the machine is allowed to move. (smart connected halui.pause connection).
When you want to dry run and have no arc okey signal, the component will say, we will not move !!!!
So the student can not dry run, what is a shame for us. But it will be solved soon. In the previous provided ethercat component, it's available as a fake button. That you cannot see because the gui interface is not provided. Only the connections are provided.
I remember posting my experience with linuxplasma so far in post at this post :
: forum.linuxcnc.org/plasma-laser/35449-an...ent?start=230#130217
Keep in mind. This is the most powerfull linux plasma application currenty in use.
In the next post Phill will have a look at my files.
But i know it's hard to follow. C code can be very confusing, and i mentioned that my component names (logical names)had to be more specialised trough the testing periode.
In the attachment of the above post, look at the signal pin in bit arc_ok_togglebutton "";
If the arc_ok togglebutton is active, in c code it goes to a separate code section called "case togglebutton" or when not active it's case is "case no_togglebutton". But in plasma world. It's very difficult to write a good component. Testing of component's are in my case alway's done on real machine's and the time it takes include testing is sometimes 2 day's or more when i start from scratch.
(remember i have a different linuxcnc distribution. My component works on a exernal offset branche cruisifide with a reverse run branche).
I can see my current offset in Z dro. I can see my actual tool path (how the thc is responding path) etc. It is still the mach3 killer in all way's. But you have to know how to install it.
Last edit: 7 years 6 months ago by Grotius.
Please Log in or Create an account to join the conversation.
- islander261
- Offline
- Platinum Member
-
Less
More
- Posts: 757
- Thank you received: 216
7 years 6 months ago #130952
by islander261
Replied by islander261 on topic Another plasma component...
Last I checked the plasmac branch uses both EO (now incorporated in the master) and reverse run.
Without working .hal and .ini files we can only get to all of the copying that will be needed to start building a working configuration. To start with make a new directory, say myplasmac or what ever you want, under ~/plasmac/configs/ using either a terminal or your distros file manager program. So by my example you will need a directory ~/plasmac/configs/myplasmac. Then copy all files and subdirectories from ~/plasmac/configs/sim/gmoccapy/plasmac/ to the directory you just created. Now you can cut the work in 1/2 if you are only going to use imperial or metric measures and not both. Delete all the imperial... or metric... files and links from your new directory and leave the system you want to use or leave both. The next part is a little tricky. Many of what you thought are files that you copied are actually just links to the real file and they are broken. I find it is easier to use your distros file manager program to make new links and replace the broken ones( they will usually have some sort of broken symbol if you use the icon view). Most of the files you will need to link to will be in the ~/plasmac/configs/sim/axis/plasmac/native/ folder. Once you have all the files copied and the broken links fixed we will be ready to make your working configuration.
My crystal ball is a little foggy lately so I really need you to post working examples of your .hal that has everything for your machine motion and physical I/O in it and the .ini file that calls it. I can post mine if you want to work it all out yourself but it is very confusing because of my pendant, gantry mechanics and hacks to allow limited control from Gcode.
John
Without working .hal and .ini files we can only get to all of the copying that will be needed to start building a working configuration. To start with make a new directory, say myplasmac or what ever you want, under ~/plasmac/configs/ using either a terminal or your distros file manager program. So by my example you will need a directory ~/plasmac/configs/myplasmac. Then copy all files and subdirectories from ~/plasmac/configs/sim/gmoccapy/plasmac/ to the directory you just created. Now you can cut the work in 1/2 if you are only going to use imperial or metric measures and not both. Delete all the imperial... or metric... files and links from your new directory and leave the system you want to use or leave both. The next part is a little tricky. Many of what you thought are files that you copied are actually just links to the real file and they are broken. I find it is easier to use your distros file manager program to make new links and replace the broken ones( they will usually have some sort of broken symbol if you use the icon view). Most of the files you will need to link to will be in the ~/plasmac/configs/sim/axis/plasmac/native/ folder. Once you have all the files copied and the broken links fixed we will be ready to make your working configuration.
My crystal ball is a little foggy lately so I really need you to post working examples of your .hal that has everything for your machine motion and physical I/O in it and the .ini file that calls it. I can post mine if you want to work it all out yourself but it is very confusing because of my pendant, gantry mechanics and hacks to allow limited control from Gcode.
John
The following user(s) said Thank You: Grotius
Please Log in or Create an account to join the conversation.
- phillc54
- Offline
- Platinum Member
-
Less
More
- Posts: 5711
- Thank you received: 2100
7 years 6 months ago #130958
by phillc54
Replied by phillc54 on topic Another plasma component...
Thank for the replies,
Dry Run:
It looks like I need to remove dry run and have torch enable/disable instead.
How should this look in the GUI's, would a checkbutton suffice or should it be a regular button that toggles the state and a separate led to indicate the state.
Gcode control:
Thanks John, I will need a bit of time to digest all this.
Chers, Phill.
Dry Run:
It looks like I need to remove dry run and have torch enable/disable instead.
How should this look in the GUI's, would a checkbutton suffice or should it be a regular button that toggles the state and a separate led to indicate the state.
Gcode control:
Thanks John, I will need a bit of time to digest all this.
Chers, Phill.
Please Log in or Create an account to join the conversation.
- islander261
- Offline
- Platinum Member
-
Less
More
- Posts: 757
- Thank you received: 216
7 years 6 months ago #130962
by islander261
Replied by islander261 on topic Another plasma component...
Phill
Please let me know if any of my rambling comments need clarification. As I have said before there is always a better way waiting to be discovered. I know Rod has put some of this in place and Pedro has as well, I hope we can hear from them. I can post some examples of my Gcode files and the SheetCam PP if you want but I think that it is not the way to go, why perpetuate a Mach3 legacy approach. Did I say I am a poor coder?
John
Please let me know if any of my rambling comments need clarification. As I have said before there is always a better way waiting to be discovered. I know Rod has put some of this in place and Pedro has as well, I hope we can hear from them. I can post some examples of my Gcode files and the SheetCam PP if you want but I think that it is not the way to go, why perpetuate a Mach3 legacy approach. Did I say I am a poor coder?
John
Please Log in or Create an account to join the conversation.
- rodw
- Offline
- Platinum Member
-
Less
More
- Posts: 12170
- Thank you received: 4153
7 years 6 months ago #130966
by rodw
With my original gcode probing routine, there was no error checking so I could disable the torch on the console and the probe would time out and go on its merry way. Now I have some error checking this won't work.
This is not quite the same but here is an idea that might be able to be adapted.
More recently, I was getting spurious probe touch offs while cutting so in the gcode touchoff , I set a motion digital output at the beginning of the touchoff routine and anded that with the probe pin. Then I turned it off when exiting the routine.That way, the probe was only ever enabled when I was actually probing! I did then think I could extend this for height error checking....
So back to Plasmac.
Perhaps you could set a pin from the GUI to disable the torch. You could AND that with the motion M3 pin to trigger the torch on relay. That part is easy! But as you are doing this all in one component, you could just add an if statement so that if the torch is disabled, the wait for probe signal code is skipped and you just move to cut height. I think that would be pretty simple to code Phill.
For the record, I spent the morning working on my plasma machine so I can get a Ohmic sense wire up onto the torch. I really have to catch up with you guys. Then a supplier stuff up cost me the rest of my plasma building time. Hopefully over Easter I might get some time.
Replied by rodw on topic Another plasma component...
islander261 wrote: Phill
I know Rod has put some of this in place and Pedro has as well, I hope we can hear from them?
John
With my original gcode probing routine, there was no error checking so I could disable the torch on the console and the probe would time out and go on its merry way. Now I have some error checking this won't work.
This is not quite the same but here is an idea that might be able to be adapted.
More recently, I was getting spurious probe touch offs while cutting so in the gcode touchoff , I set a motion digital output at the beginning of the touchoff routine and anded that with the probe pin. Then I turned it off when exiting the routine.That way, the probe was only ever enabled when I was actually probing! I did then think I could extend this for height error checking....
So back to Plasmac.
Perhaps you could set a pin from the GUI to disable the torch. You could AND that with the motion M3 pin to trigger the torch on relay. That part is easy! But as you are doing this all in one component, you could just add an if statement so that if the torch is disabled, the wait for probe signal code is skipped and you just move to cut height. I think that would be pretty simple to code Phill.
For the record, I spent the morning working on my plasma machine so I can get a Ohmic sense wire up onto the torch. I really have to catch up with you guys. Then a supplier stuff up cost me the rest of my plasma building time. Hopefully over Easter I might get some time.
Please Log in or Create an account to join the conversation.
Moderators: snowgoer540
Time to create page: 0.724 seconds