[gnea/grbl-Mega Issue#63] Has anyone had success running a plasma table with this setup?

#1 – swarfer 于 2018-05-27

I have run GRBL at 1 step/mm without any problem.
70ipm is 1778mm/min which is not slow. GRLB does have a lower limit but I don’t think this is it.
A typical belt drive machine would use 26.666 steps/mm which works just fine above 45mm/min

To test to see if your problem is the low speed limit you can turn off AMASS in config.h
Motion will not be so smooth but it can go really slow.

#2 – langwadt 于 2018-05-27

@neomadic how did you eliminate EMI as a source of the issue?

#3 – neomadic 于 2018-05-27

@swarfer Thanks for the advice and info. That’s good to know and what I suspected from the specifications. It seems to me that lower step/mm rates would be easier to drive. 26.666 steps/mm is exactly what my setup needs in 1/8 microstepping mode but it’s missing steps and locking up at the speed I need for plasma cutting at that setting. Accuracy would be fine for what I need at 1:2 microstepping, which would put my steps/mm setting at 6.667, but the motors only run a few steps, roughly, and everything resets when I switch over my external drivers to 1:2 and change $100 and $101 to 6.667.

Are you running grbl on a mega? I hoped that the protoneer board whould do what I want to do, which is why I bought two of them, but both systems gitter and error at less than 1/8 microstepping and alarm or reset randomly for no apparent reason at 1/8 microstepping and above. If I geared up the table so I could use settings like 150 steps/mm, everything seems to work perfectly.

I’m going to go over everything one more time later this afternoon, hand write some g-code, try some different post processors, and basically just make sure that I haven’t missed something stupid. Any troubleshooting after that will require either getting an oscilloscope or using another arduino to monitor all of the inputs and outputs so I can see where the problem is,

@langwadt
I used shielded cables, star grounding, filter caps on the inputs, have played with debouncing, and positioned all cables and components strategically. Everything is in a metal case that has a good earth ground. I know for sure that I’m not getting any EMI from the plasma cutter because I’m just testing the controller with the steppers on the bench, simulating limit switches/probing, and triggering ttl relays for thc and torch control. If you have any ideas that I haven’t tried, I’d definitely be interested to hear them.

#4 – langwadt 于 2018-05-27

@neomadic EMI works in mysterious ways so just because you did everything right it doesn’t mean it’ll always work, but if you are not running the cutter then you should be safe. I’d suspect a powersupply problem, try running without the drivers (or motors)

#5 – neomadic 于 2018-06-11

@langwadt

You nailed it! Twice!
I was tuning the collision sensors and saw the led on one dim. The power supply output was all over the place at 0-19-26v. Pulled it apart and found a blown out solder joint on the main transformer. Once I got that going again, I determined that the 24v relays that I’m using to convert the collision sensors to 5v signal throw enough emi out of their coils to trigger the abrt/reset inputs, but only when they bounce. Once I got them adjusted for a clean off/on, everything’s all good other than the thing randomly quitting in the middle of a cut for no apparent reason. Probably still fighting EMI somewhere.

#6 – langwadt 于 2018-06-11

what pull-ups and filtering are on the input pins on that board?

#7 – neomadic 于 2018-06-11

That’s an excellent question. I’ll have to crack the case open on one and check it out. I can’t find it mentioned anywhere in the documentation. It’s a Protoneer v2.58.

The stoppages I’m seeing are so few and far between that I’m really not too worried about them. This unit is installed at a fab shop with welders, grinders, and hydraulics all tugging on the power grid so I want to install a power conditioner and make a metal cover for the pi/protoneer shield. I’m thinking that curing obvious environmental issues first makes more sense than digging into building filtering/debouncing circuits, but I’ll probably end up doing that eventually too.

#8 – langwadt 于 2018-06-12

a reasonably low value pullup (i.e. not just using the internal one, many switches and relay will want atleast a mA to switch realiably) and a capacitor to filter out spikes will solve a lot of problems

#9 – Protoneer 于 2018-06-12

680r
0.047uf

On Tue, 12 Jun 2018, 12:03 langwadt, wrote:

> a reasonably low value pullup (i.e. not just using the internal one, many
> switches and relay will want atleast a mA to switch realiably) and a
> capacitor to filter out spikes will solve a lot of problems
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/gnea/grbl-Mega/issues/63#issuecomment-396423714>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/ADqFI-OyEDzv0sMOgM3xWSN3jjwtnej0ks5t7wVFgaJpZM4UPBsB>
> .
>

#10 – neomadic 于 2018-06-12

Thanks Bertus!

I think I may need to build a little circuit to debounce the actual proximity sensor outputs because as long as the relays get a good solid trigger, I don’t seem to have any issues.