Another plasma component...

More
19 Apr 2019 06:33 - 19 Apr 2019 06:40 #131219 by phillc54
I have pushed another update:
- 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:
configs/sim/axis/plasmac/native/plasmac_axis.py
configs/sim/axis/plasmac/gladevcp/plasmac_panel.py
configs/sim/gmoccapy/plasmac/plasmac_config.py
configs/sim/qtvcp_screens/plasmac/plasmac_ui_handler.py

Cheers, Phill.
Last edit: 19 Apr 2019 06:40 by phillc54.

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

More
19 Apr 2019 07:00 #131226 by rodw
Replied by rodw on topic 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!
The following user(s) said Thank You: phillc54

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

More
19 Apr 2019 12:30 #131233 by rodw
Replied by rodw on topic Another plasma component...
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.

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

More
19 Apr 2019 16:13 #131245 by islander261
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

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

More
19 Apr 2019 18:20 - 19 Apr 2019 18:30 #131253 by islander261
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.

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')

John
Attachments:
Last edit: 19 Apr 2019 18:30 by islander261. Reason: Added terminal output.

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

More
19 Apr 2019 22:36 #131258 by rodw
Replied by rodw on topic Another plasma component...

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.

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

More
20 Apr 2019 02:37 - 20 Apr 2019 03:52 #131267 by phillc54
John,

I have just finished setting up my test rig in a similar configuration to yours and have no problems with probing.
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.

Cheers, Phill.

EDIT: I just 'cleaned' up my configs and had the same error...:(
Last edit: 20 Apr 2019 03:52 by phillc54.

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

More
20 Apr 2019 04:01 #131273 by islander261
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
The following user(s) said Thank You: phillc54

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

More
20 Apr 2019 05:08 #131274 by phillc54
In my 'cleaning' up I managed to disconnect the ohmic and float pins...
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.

Cheers, Phill.
The following user(s) said Thank You: tommylight

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

More
21 Apr 2019 00:57 #131352 by phillc54
In this post I asked about resetting offsets at the end of each job.

I think I am going to go with this unless there are valid reasons not to as it means keeping track of the Z axis is much neater.

Cheers, Phill.

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

Time to create page: 0.142 seconds
Powered by Kunena Forum