Another plasma component...
- fix probe setup for opposite z coordinates
This should fix problems for machines with Z zero at the top.
Mine has Z zero at the bottom and I didn't test for the other variation.
plasmac.comp is changed so make is required
GUI files changed are:
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!
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.
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.
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.
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.
File Attachment:File Name: probe_test.ngc
File Size:0 KB
I also found this in the terminal that I have never seen before:
RUN IDLE No option 'offset_axis_z' in section: 'DEFAULT' (<__main__.gmoccapy object at 0x7fc409b3a2d0>, <Dialogs object at 0x7fc3f57b9f00 (Dialogs at 0x1fd5c20)>, 'alert') ('MDI Mode', False) 3 2 RUN ohmic probe detected before probing.ohmic probe detected before probing. /home/jd/plasmac/lib/python/gmoccapy/notification.py:168: GtkWarning: Invalid icon size 48 self.popup.show() (<__main__.gmoccapy object at 0x7fc409b3a2d0>, None, 'error')
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.
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.
I have just finished setting up my test rig in a similar configuration to yours and have
Yay, I can now do macros in Gmoccapy and I also learnt (after much hair pulling) that you cannot have a ngc file in the ncfiles directory with the same name as one you are trying to run from the config directory...
Is it possible that the 0.38 probe height is actually lower than the surface you are probing to.
Probe height is the distance above the Z axis minimum limit.
EDIT: I just 'cleaned' up my configs and had the same error...
So I have tested Axis and Gmoccapy in metric and imperial with Z zero at bottom and Z zero near top and all were successful with the current version of the branch.