Another plasma component...

Zultan wrote:

but I was wondering if it would not be better if the line was:

net p_comp:axis-position        axis.z.pos-cmd              =>  plasmac.axis-z-position

my brief check in hal config told me that these should be equivalent but I dont have enough Linuxcnc experience to be sure...
Glenn

I kinda think that is more correct for the 2.8 master branch Plasmac is based on. The reason for this is that one significant change from V 2.7 to V 2.8 was separating the dependence between axes and joints. In the case of an axis with 2 motors, the axis don't really exist until the machine is homed. I wondered if external offsets might make the joint vs axis be different but I don't think so.

You can't assume a given joint represents a specific axis anymore

Phil

Ok, I'm dumb, saving works fine you just have to hit enter after changing a value. Saving works on both renamed and original named machine. Sorry for wasting time.

Glenn

Phill

I managed to do a few (9) line tests today. The results were mixed. But first here is the test program:This was launched as a MDI button from the bottom of the MDI screen.

I had a bunch of trouble using the dry run button (something I will never use in production work). It needs to show a change of state when it is active. Things got very confusing when trying to use it, most likely operator error. I had to shut down and restart gmoccapy to re establish predicable behavior.

While the probing test worked reliably on clean dry sheet things didn't go so well on a dirty wet one. Problems with the torch going down to the sheet surface with the Ohmic Probe LED coming on and then the torch just moving +/- .005" up and down by the DRO. The Ohmic Probe LED would sometimes briefly change state. It would do this until 30 second timer had timed out and then raise the torch.

The line tests proved less than reliable, the best I did was three in a row without a problem. Most of the problems involved some sort of probing failure. Sometimes the failure was as above but with a twist. Because there is no timer to force a time out the only way to stop the torch bouncing was hit the program stop button. At this point retries resulted in the same failure even after cleaning of the torch and material. The only way to recover correct operation was to shut down gmoccapy and restart it. On several tries the torch would move part way down and stop and fire well above the sheet surface. Stopping the program sometimes fixed the problem and sometimes didn't. Twice at the end of the cut the torch dove into the work piece only to raise up again. Once to the starting position and once into the upper limit switch. I expected the torch to raise to the safe height between cuts, some times it did and sometimes it didn't.

The good news is that THC appeared to work very well, I got the pgain up to 40 and the deadband at .1v and had no sign of oscillation and the height control was solid at the set point. The Z axis did not appear "nervous" at all. Halscope plots showed no sign of hunting or overshoot. The corner hold LED came on at the end of the cut as it should. I am very happy with how the THC works with the straight lines given the terrible time I have had previously with the EO branch. I now need to get a PP working for the plasmac branch so I can test with one of my normal pieces.

I don't know what I did but the configuration and materials files are now working correctly!

I need some guidance on what information I need to collect for you. I just don't have a good enough understanding of the plasmac component to do more than start looking a random signals.

John

Phill

I was really impressed with how well the THC worked, right now I am sure it is the best I have seen with any equipment I have owned.

Ok, I will increase the debounce time and try it. I actually went as high as 5 yesterday when chasing my tail. My floating head has nearly .25" in compliance so slowing down the response isn't a problem. My table is in rough shape right now because I don't have the couple of days to remove,repair, replace and re-level all the slats right now. So this is a good real world test in poor conditions.

My present system when probing rapids the torch down , this maybe from safe Z or from G53 Z0, to just above the thickest plate I can cut (i have no idea how I will get it on the table) .650" then proceeds at slow speed until contact is made. Then I move it down another .005" just make sure the contact is good. I then slow the speed down by 16 and raise the torch until contact is broken.

I have used several systems that used the no Z start the THC with M3 and end with M5, and all suffered from horrible IHS because of poor probing. Please look at the Gcode I posted a while ago about for probing. I didn't get to that point by accident. I can post an example of the Gcode my present production system uses if you want. Probing is easy if you only ever use 6-8mm and thicker plate (so is cutting in general).

Questions now. At what height is the torch supposed to go at the end of the cut? When cutting a file we want the torch to go to safe Z between cuts and at the end of the file we want the torch to go to G53 Z0, the same as error conditions. Even the commercial systems that use external THCs re synchronize the work piece top surface (G54 Z offset) at each probing, some at the probing and some at the end of the cut.

I am going to have to hack you plasmac_monitor code, my old eyes can't deal with the low contrast/low brightness arc voltage display! Actually once this is working well and stable I will most likely move all indicators to the plasmac_monitor code and put both Gladevpc tabs behind the preview tab.

John

Phill

Thank you for the operation instruction, what I am seeing makes much more sense now.

I know how to update the whole branch from git, haven't tried individual files yet. If you are only making changes to one file I should be able to manually deal with that if I get a path to it. So do what is best for your work flow and configuration management sanity.

I may have to ask for help when I go to split up the handler file for the Gladevpc panel. I can copy and imitate python code but get lost quickly when starting from scratch.

Gmoccapy is really easy to change the screen and access tabs behind the preview screen. You have all ready put modified screen bits in your present config and tabs behind the preview screen are exactly the same. For tabs behind the preview screen you want the EMBED_TAB_LOCATION = ntb_preview. each of your current Glade files and handlers will need to be broken into separate files for the tabs to be at the top level or for easy testing you can just use the the as is files and end up with a top level tab that brings of the glade file and its tabs will become visible as sub tabs. I will attach an example of my playing with the later approach, this is not finished work only an example. Running Gmoccapy is like operating a CNC milling machine without all the assumptions many plasma and router table controls make. I find that I rather like the work flow because it it very similar to that of my mill.

I have a lot of production work today so I may not get any more line testing in till tomorrow.

John