Showstopper Plasma Cutter retrofit

rodw wrote:

snowgoer540 wrote:

Reading how much you like being on the "bleeding edge", I'm a drop curious why you didn't use the master branch? It does have a few more features that are not present in 2.9. It's also noteworthy to mention that at this point, 2.9 is considered "end of life" from a development standpoint (to include bug fixes).

Thanks. I actually asked  here which version to use for production and 2.9 was recommended.
forum.linuxcnc.org/plasmac/53044-best-qtplasmac-version-to-use
I also built the 2.9.x ISOs on the Linuxcnc downloads page soi maybe I am biased. For a production setting on a machine 1800 km (over 1000 miles) away for a user, using a production version  made a lot of sense.

Its not that the buildbot is broken but V2.9 is frozen following a release. Release debs for  2.9.3 are in the Linuxcnc repository which can be installed on any linux distro by running the bash script mentioned here 
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel
(or by using the ISO)

Checking the release version of QTplasmac in Linuxcnc 2.9.3 , I see it is 2.9-238.314. It seems your last release for 2.9 was not included. It will probably get in there if ever a 2.9.4 is released.

I might write a script to convert from using the Linuxcnc repos to the 2.10 repos at  buildbot2.highlab.com/

 

Yes, I understand the difference between the released debs and the buildbot(s)... the key word there was "if" you used the buildbot(s). Either way, the buildbot(s) is most definitely broken and I'm officially sorry I said anything.

Anyway off topic for long enough, The main issue for us is the breakaway. It really makes no sense that it will not work when all the pins are set correctly as inputs into plasmac.comp. I will look at the state of the plasmac.comp output pins to halui as it might not be a qtplasmac issue. All of these features were working years ago so its odd they have broken.

 

QtPlasmaC does not appear to be the issue:

Virtual Machine on 2.9:


Actual table on 2.9:

Hey everyone,
New to the forum so be gentle.
This post is about the upgrade happening in my workshop at Steel Cut and Create in melbourne.

Firstly in case anyone wants to know Rodw has been great to deal with from the first contact. I have been very impressed with the work he has done on his end. We have progressed through a range of issues and he is very clever and has stuck with it the whole way. It has been difficult because he is doing all of the work remotely, but everything that Rod does is documented soo well that there is always a starting point for troubleshooting.

I have uploaded a video of our current situation to help with trying to get a solution:
drive.google.com/file/d/14DREIxArgDyoQFU...4u3/view?usp=sharing

I will make a better video of everything once it is all finished and running properly.
Regarding the control box on the gantry--- Did it have to go there? No.
Did we consider mounting it seperate? Yes.
Did I do some testing on the old system with extra weight to see what would happen? Yes.
Now that it is all in place I do not like the control box running around on the gantry, but it isn't a big deal because the project still has a way to go before it is finished. I will plan to move it off the gantry now that I see the effect. This decision will be in an attempt to reduce pressure on the running gear (pinion gear and rack, motors); to be able to increase the speed of operation; and to reduce the impact in the event of a crash.

Do any of the issues change if you run the machine with the references to runstep.hal and/or pendant.hal commented out in the ini file?

 

Thanks phill that looks like the right place to look.
When pendant.hal is commented out on its own:
The breakaway pauses the program but only during the rapid movement.
nothing else changes.
When runstep.hal is commented out on its own the following happens:
The breakaway works correctly and stops the program in the event of a collision.
The cut recovery panel comes up when the pause button is pushed or a break happens causing a pause.
The z safe travel height is working as it should.

phillc54 wrote:

Do any of the issues change if you run the machine with the references to runstep.hal and/or pendant.hal commented out in the ini file?
 

Phil, thanks for that. It flashed through my mind to check that and I promptly forgot about it. Good Sleuthing.

It may be easier to use two of the existing external hal pins rather than using runstep.hal.