Another plasma component...

Glad to hear you are running Z0 at the bottom Phill. I started at the top but had all sorts of trouble so changed the Z axis direction around early in the piece so I did not want to change.

Don't forget the config issues for torch voltage on the GUI as its basically useless as it is now. Feel free to steal my code. If I get some time once I'm cutting again, I might try and fold that into plasmac for you I tried to build in everything about voltage into that single component.

phillc54 wrote:

Ohmic Test - John uses this to test for a shorted torch, it turns on the ohmic-enable output

John, it would be good if you could explain this a bit as I need to understand this so I can use my as yet unused ohmic sensor!

Also some ballpark pid settings would be good. Not looking forward to tuning all over again!

I reread this entire thread this evening and also noted that there had been some discussion about setting data from gcode. Then while pondering a more complex data problem with about 64,000 records, I think I solved how this could work.

What if the plasmac materials list was the master of all cut settings?
Then if every entry in the materials list had a unique numbered field (eg 1,2,3,4...999)?
Then let the gcode send one number to plasmac using M67/M68 on say motion.analog-out-00
Then let Plasmac set the material list according to that index number
Then cut the file as if the user had set the dropdown to that record number?

I have not looked at the code base but I'm assuming the materials are managed in Python (Certainly this would be the case in Gmoccappy surely? If thats the case, it'd be pretty simple to store the materials in an array and retrieve a given entry according to index number in that array?

Any thoughts? This is about as simple as it gets and very easy to build into say a Sheetcam post.

Phill

Than you for adding to the code. I was just going to cut the offending portions out of the code, except for the setting ranges everything had been working fine. I may get to testing today. My old mill has the operation program stored in EPROMs so there is no changing how the manufacture intended it to be used. I know the Z 0 at the top of travel was done to make the tool length compensation easier to use (floating point by SW on a '286 processor!). Kind of a relic like the operator. The reason early low cost plasma tables had to have machine Z 0 near the top of the slats or material top is that Mach3 had/has no way to probe so they used re homing the Z axis to get the top of the material.

Rod

The most common failure for the ohmic probing is having the torch nozzle shorted to shield either before probing or during probing when the torch isn't in contact with the work piece. This is really bad with the HT Finecuts where there is such a big space between the nozzle and the shield for debris to get into. So when using the consumables that you are most likely to use with thin sheet using ohmic probing you have most shorted torch failures. BTW the stock firmware in your power supply does this while cutting when using the automation torch (error 85). The ohmic test button just connects the ohmic probe circuit so you can test if the torch is shorted from the console, saves having to get up and take the shield off the torch just to find out the post flow air pushed the debris out of the torch.

I don't think that you will have any issues tuning the THC using plasmac. Mine worked with the default settings, that is one of the reasons I now think this branch is the way to go. I increased the stock P gain and reduced the deadband a lot and still didn't get the torch to oscillate or grossly over shoot during line testing. Torch actually never even got "nervous" at higher gains. I had no need for any I term or D term (gain at 0). So now I am running a P gain of 25 with a deadband .1. I am sure that I can get better but the present performance is so much better than anything else I've used no change is necessary.

It sounds like your proposal for a material table is similar to other systems. On most CNC Machines this would be called a tool table and not a material table. Of course at this time the LinuxCNC built in tool table isn't very flexible the way it works right now. Maybe this is the time to propose a good user definable way to extend the LinuxCNC tool table handling? I am thinking that maybe we define entries in the table by tool number and they can be changed using the stock Gcode blocks? If we have a kerf width (tool diameter) field then the usual G41-G43 blocks can be used to define cutting offset. The thing I would like is if the format for the material/tool table is compatible with SheetCam so a single file can be used for both. The main drawback to the tool table in CommandCNC is there is one copy for it and another copy for SheetCam so it is up to the user to keep them synchronized. BTW you can add fields to the SheetCam tool table by defining them in the post processor. I will leave it to you good coders to figure this all out. I only use about 8 different tools (cut parameters) so I don't need a huge table, on the other hand someone with a job shop will need a library of materials or tools. Manually changing tools is a PITA when cutting, right now I am just using M1 pauses at tool change until plasmac has this feature.

John

Phill

I tried to test the latest release and couldn't get the probing to work correctly while doing static testing. Both the ohmic and float switch probing did the same thing except for displaying the appropriate error message. I was using my probing test program that activates the plasmac.probe-test pin to start the probing. What happens is the probing starts with the torch at machine Z0 (G53 G0 Z0) which is near the top of the Z travel on my machine. The torch lowers at the Setup Speed until it contacts the material surface activating either the ohmic probe or float switch. The torch motion stops and the appropriate error message "... detected before probing." is posted to the screen. At the end of the test delay (to give time to check actual physical height when things work correctly) the plasmac.probe-test pin is de-asserted and the torch returns to machine Z0. Please see attached screen shot and code.



I also found this in the terminal that I have never seen before:
John

islander261 wrote:

It sounds like your proposal for a material table is similar to other systems. On most CNC Machines this would be called a tool table and not a material table.
John

It didn't dawn on me that I'd come back full circle to the tool table last night as I was in data mode not CNC mode. I'll have a bit more of a think about that. It might work to our advantage that Plasmac has its own definition for materials/tools so we just need a tool number in the "plasma tool changer". Andy did propose a SQL schema at one stage but it never did get adopted. SQL would allow a separate plasma table to be attached to a tool number very easily.

Phill, maybe you could add an extra TOOL_NUMBER setting to your materials file format as a first step towards this and then we just need to hook up the tool changer module later on.

Phill

Thank you, now that I know how it is supposed to work the correct .ini values fixed everything. I will try and test tomorrow.

John