Void Lock Kerf Crossing suggestion

More
23 Apr 2020 11:43 #165231 by rodw

Exactly, what I meant was "PlasmaC was designed to have its own internal kerf crossing"


Well when I nail it and its published as an opensource component, you can steal my code...

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 11:46 #165234 by phillc54
Thanks but it would have been nice is if as I said before I had some testing and feedback done on what I have obviously wasted my time on.

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:04 #165242 by tommylight

......................... on what I have obviously wasted my time on.

As i said to a client after scraping 2 useless tables for robot welding, and thinking how to do the third:
This was not a waste of time and money, we learned something, we learned what does NOT work ! :)
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:06 #165243 by rodw

Thanks but it would have been nice is if as I said before I had some testing and feedback done on what I have obviously wasted my time on.


I had a whole working plasma config that I wasted hundreds of hours of testing and experiments with Dewey's hpid component and his then experimental branch of external offsets that you worked out how to use. But I know a lot of that foundation work by others and myself found its way into Plasmac.

I did say at the time that I did not think you were following a workable kerf crossing algorithm... and did share my methodology and early code very early in the piece...

I think I have worked out how to turn the THC back on. I will save the torch voltage when the void hold kicks in and when it falls below that point, I'll trigger the off signal. I actually had code a bit like that in the component today but I deleted it.

The plots from today are by far the best void crossing ones I've captured so after looking at them, I think that approach will work. From what I can see, it naturally falls below that level but time will tell.. In my research I came across one system that just timed out and tried to enable the THC again

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:07 #165244 by phillc54

......................... on what I have obviously wasted my time on.

As i said to a client after scraping 2 useless tables for robot welding, and thinking how to do the third:
This was not a waste of time and money, we learned something, we learned what does NOT work ! :)

Ha Ha, thanks Tom but I don't even know if it doesn't work. :unsure:
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:11 #165245 by phillc54

But I know a lot of that foundation work by others and myself found its way into Plasmac.

Most of how PlasmaC works is from the Toma config, just all wrapped up in one component.

I did say at the time that I did not think you were following a workable kerf crossing algorithm... and did share my methodology and early code very early in the piece...

Yes, you were quite negative about it. I also recall you saying the same about my THC.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:26 #165248 by rodw

But I know a lot of that foundation work by others and myself found its way into Plasmac.

Most of how PlasmaC works is from the Toma config, just all wrapped up in one component.

I did say at the time that I did not think you were following a workable kerf crossing algorithm... and did share my methodology and early code very early in the piece...

Yes, you were quite negative about it. I also recall you saying the same about my THC.


I saw the light and let you do the coding but you failed me on the kerf crossing :)

I was never keen on the single component (Plasmac has 1373 lines). Its not really consistent with the Linuxcnc design which is based around small modular, discrete components. (eg. THCAD parsing, corner lock, kerf crossing, voltage sampling etc). While it might have taken a bit more effort in hal to tie it all together the modular approach would be much more maintainable.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:29 #165249 by tommylight

But I know a lot of that foundation work by others and myself found its way into Plasmac.

Most of how PlasmaC works is from the Toma config, just all wrapped up in one component.

That was not easy, for sure. That config has everything automated in hal, and just following what is going on there is a mess. I do not remember much of the work i have done at the beginning several years back, but i do remember when i made it work with Mesa and servo systems, i still have 3 or 4 pages of scribbles trying to follow joint command and joint feedback through it.
-

But I know a lot of that foundation work by others and myself found its way into Plasmac.

Most of how PlasmaC works is from the Toma config, just all wrapped up in one component.

I did say at the time that I did not think you were following a workable kerf crossing algorithm... and did share my methodology and early code very early in the piece...

Yes, you were quite negative about it. I also recall you saying the same about my THC.

Since you two are bickering about it, i do recall writing here that the only way to do that properly is DV/DT. Or did i ? :)
As i see it, both of you ( and others ) did a magnificent job of making all this work properly and having features that most of the industrial plasma machines lack.
Again, i will point out that looking at a plasma machine while cutting it all seems very simple, but nothing related to plasma cutting is simple. Cutting metal like butter is no easy feat, and being able to build such a machine in a shed and have it work all day every day without a hiccup is only made possible by such persons as we have here, putting endless hours of work without expecting any reward for it. But it sure as hell is fun ! :)
The following user(s) said Thank You: Clive S, rodw

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:37 #165251 by phillc54

That was not easy, for sure. That config has everything automated in hal, and just following what is going on there is a mess. I do not remember much of the work i have done at the beginning several years back, but i do remember when i made it work with Mesa and servo systems, i still have 3 or 4 pages of scribbles trying to follow joint command and joint feedback through it.

That is a great piece of HAL work Tom. I think it took me about a week to draw it out into a format I could understand.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
23 Apr 2020 12:43 #165252 by rodw
I think Phill should really take the bulk of the credit. He has done an amazing job rolling up everybody's ideas into a coherent package.

I know I pushed hard to get some inclusions but then Islander261 had got Phill to do what he needed before me, now Stephan has pushed Phill on the RS485 not to mention Tommy in the background.

There is no doubt that plasma control is enormously complex and not well understood outside of a few major global manufacturers but it does kinda get you in. The knowledge in this forum is amazing, not to mention the flood of users trying to adopt Plasmac. The info we've published is by far the most comprehensive info about the process on the internet anywhere.
The following user(s) said Thank You: tommylight, Clive S

Please Log in or Create an account to join the conversation.

Moderators: phillc54
Time to create page: 0.106 seconds
Powered by Kunena Forum