Hypersensing with THCAD - better way to do ohmic sensing

You may also like to look at motion.motion−type which is real time and reports the state. There is a pin for traverse which I assume is rapids. It also has a state for probing so it might do exactly what you want... I have used this pin so know it works.

Well, I cut 1.5 copies of the nest I shared previously today. For some reason, now I have a water table, I am seeing 22 volts or so when not probing so I had to adjust the off threshold quite high. But it still probed happily. I will look into that.

Note to self. Don't unplug your LinuxCNC PC from the power half way through a massive nest while checking the earth clamp!

I learnt a lot about Sheetcam today. There is a cool option to program a move under the Operations menu which is great to sever a sheet off after cutting a partial sheet like that job which is 900 x 1200. Thanks to Phill who helped me work it out off forum. You need to add 2 operations. A rapid to the point you want to sever from and then a cut with a feed rate to sever the sheet. Its a bit haphazard where it puts the code thought. I tried a few things to move it to the end.

Also if you do have a disaster and you can't resume, you can click on the part in the nest and it will highlight the part. so it might be "Bottom Bracket Duplicate 23" So then I opened the Gcode file and searched for "Duplicate 23", made sure it was the bottom bracket, not the top bracket. Then I just needed to delete from that point back to the beginning of the file. Pretty quick and easy really.

phillc54 wrote:

That would take some code changes to plasmac.

If you want realtime you could set motion.feed-inhibit to 1 which pauses motion. You would probaly need to latch it for safety because as soon as it resets to 0 the motion will continue.

If user space is good enough you could tie into:

net plasmac:program-pause        plasmac.program-pause           =>  halui.program.pause

this exists in plasmac.tcl, you would need to break it and or it to your connection I guess.

Neither of these methods would give you an y error messages, they would just pause the machine.

So I've tried it both ways that you suggested and they both work pretty well, I just thought it could be a little quicker. Perhaps my servo-thread is too slow (SERVO_PERIOD = 1000000) or I just have unrealistic expectations and that is what the mag breakaway is ultimately for. I'll have to do some more research on commercial systems that use this form of collision detection and see whats realistic. Obviously it can't be instant, and at high rapid speeds that is not to be expected.

Thanks for the help thus far to both of you. Once I do a little more testing while cutting, I'll post the modified component and hal file I'm using, if its of any use to anyone else. Hopefully I'm not causing more problems then I'm trying to solve

Setting motion.feed-inhibit true will stop as fast as your acceleration settings will allow.
You _may_ be able to stop faster by disabling the stepgen, and violating the acceleration
constraints, but this could possibly cause damage to the mechanics. There are also some
more tricky ways to have a higher (but controlled) deceleration on a fault with some hal file wiring.

rodw wrote:

Well, I cut 1.5 copies of the nest I shared previously today. For some reason, now I have a water table, I am seeing 22 volts or so when not probing so I had to adjust the off threshold quite high. But it still probed happily. I will look into that.

I have to say, I'm happy to see you're dealing with this as well (sorry). For initial setup and testing, I've decided to go back to your stock config and put my collision detection modifications on hold until I can get the basics setup. I've been pulling my hair out recently over some issues that I just couldn't figure out.

Last night, I had some issues where ohmicsense.ohmic-volts was hovering around 0v and the ohmic cap was not touching anything, yet hitting probe test button would result in the ohmic light turning on. Consequently, anytime I tried to run a program it would immediately halt as the ohmic sensor was "tripped". Mind you, ohmicsense.ohmic-volts was still reading 0v and the ohmic cap still wasn't touching anything. The interesting thing is that when I removed the plasma work clamp from the table, the ohmic light would go off and it would probe happily and ohmicsense.ohmic-volts would shoot up to 23~24v when it touched the material. The problem persisted whenever the work clamp was connected back to the table (which is connected to earth ground). This made me think it was a software issue, not reading ohmicsense.ohmic-volts properly, yet it had influence from the work clamp.

This morning I decided to take a look at it again and change my debounce settings. I increased the delay and it appeared to have solved the issue, I wasn't getting false triggers in any configuration - work clamp attached or not. However, after setting the delay back to its original value, all seemed fine as well. This didn't sit right with me because it magically was working, however the config was the same as it were the night before. I loaded up a test program, and it ohmic sensed properly and cut the part (just a straight line, one pierce). However the issue was back, but in a slightly different form.

Reading ohmicsense.ohmic-volts after a cut, (ohmic cap not shorted on anything), I was getting a steady 18-19 volts. If I removed the work clamp from the table, it went to 0v. I monitored this voltage over a span of about 20 minutes. It very slowly decreased down to ~1v and the ohmic light turned off, and I assume would have made it back to 0v. I tried grounding several points with a 10awg wire; didn't seem to help speed anything up. When I removed the ohmic wire attached to the spade connector on the ohmic cap, ohmicsense.ohmic-volts went back to 0v as it was now floating and not connected to the torch. I measured the voltage between the ohmic cap (wire attached) and the water table, which is connected to earth ground. Sure enough, I was getting the same reading that the THCAD-5 card was reporting, 18-19 volts.

Why am I seeing a residual voltage after a cut? Why does removing the work clamp solve this? Is there a ground loop getting charged? The way that the voltage slowly drained down to 0v made me think of capacitors discharging in a very slow manner. If only we were able to speed this process up by putting a load somewhere...

Let me know if you can reproduce any of these symptoms. I'll have to try an "off" voltage of about 20v and see if it works, because it still goes to about 24v when the ohmic cap is shorted, just like it should.

Edit: Did another cut as the voltage has drained off an no longer triggered the ohmic sensor. Recorded different voltages post cut.

Condition: Ohmic wire attached
Ohmic cap to Earth Ground (through water pan) ~11v

Condition: Ohmic wire removed from cap
Ohmic cap to E. GND ~1v initially, drains towards <100mV as measuring. This seems true, do not expect any voltage on the cap with wire removed

Ohmic wire to Water table ~22.3V; very stable, no fluctuation in reading

Work clamp (removed from table; floating) to water table: 20.61V

I set the "ohmic-low" voltage at 20V and it didn't seem to matter. Even though ohmicsense.ohmic-volts was around 16-18V after a cut, the ohmic sensor pin was still triggered until the work clamp was removed.

Sounds like maybe your 24V supply is not fully isolated or that you have
leakage in the wiring (something wet?)

It might be easiest to diagnose this with an Ohmmeter

Attached shows how I have my ohmic sensing power supply connected. 120v AC coming in, no relay, always on. The 24V- side is tied to earth ground. My water table is connected to a star point on the table where I've tied in earth ground.

I recently went through my cabinet and tried to remove all unecessary ground connections in hopes of removing any ground loops I've created. Currently, my V- (common) on my logic 24V psu (separate from the hypersensing PSU) has continuity with earth ground. Should this be disconnected and the common rail be separated? My 48v stepper PSU common is totally separate (or so I think), but I can't quite find where the 24V common is connected at. Could the fact that the 24V common (logic PSU) connected to E.Gnd, which is also where the hypersensing PSU V- is connected to cause for it not to be isolated? I'm still not totally sure how to check for this.

Any help is greatly appreciated. Thanks!

Thanks Peter, Would grounding the plasma cutter chassis to the table help?

My powersupply is an isolation class II device with isolation resistance of 100 M ohms at 500V so I don't think isolation is an issue. See oceancontrols.com.au/files/datasheet/mw/psm-170_HDR-15-SPEC.pdf

I'll have a look later today. At the moment my water tray is empty so I'll do some tests with and without water.

What I did was open halshow and watch the ohmic volts pin for a while while probing manually with my MPG and set the low limit to be a bit above the observed voltage. I think I set it to about 22.5 volts and then set the ohmic on voltage to 23.5 volts.

With those settings, I cut one nest with over 500 pierces and I never had a probing fault.

From my testing, I don't think its unusual for water to get up in the nozzle so it may be bridging the electrodes. Earlier, with a low off threshold, I had more issues like this at higher amperages which I assumed was due to the larger hole diameter in the tip.

Anyway, the good news is we have the ability to dial it on to suit our conditions in HAL.

I would disconnect power and the THCAD and the measure the resistance from the probe to the table

Edit: disregard previous

Turned off all power to everything. Plasma cutter still plugged into wall, but off.

24v isolated psu is unplugged
Thcad-5 input and output connectors, unplugged

Wire on cap, resistance between torch shield and table: 2.3MOhms

Wire removed from cap, torch shield to table, resistance is still 2.3MOhms

Work clamp removed from table, open circuit, infinite resistance

Plasma torch to work clamp resistance is 5.6MOhms