Advanced Search

Is Electromagnetic noise from the VFD ruled out?

Hello,
I am scratching my head for days trying to solve a spindle problem. I have setup 2 other mesa boards and everything was fine.
When I attempt to start the spindle (M3 S12000) or click forward in the GUI the spindle starts then stops about 1 second later.
I did have On_Abort_Command setup and it called the abort which is the only thing I can get it to log. If I change the VFD to manual control the spindle works fine. Testing the 10V spindle out seems to be fine for the 1 second then drops to 0v. The machine almost always goes to "Machine Off".
The only differences to the other machines is they have dual Y and the size of the VFD.
I ran pncconf to setup a blank 3 axis limited machine for the 7i96s, axis work fine but spindle still causes the machine to reset.
My hal and ini are a mess from testing once I clean them up a bit I can upload them if needed, they are out of the box from the pncconf.
Motion seems to be fine, limits are working. I went through the .INI and .HAL line by line comparing all spindle items and found them to be identical. But of course the others work and this one faults.

Good morning Aciera,

I would be really happy if you could find the time and willpower to lift me up a little bit

I attached, hopefully my complete config incl. .comp & .py , config in the zip archive but  just to be sure i attached my vismach config separately.

Kind regards,
Jochen




 

OP-
I just re-read your first post and see that you want to be able to dial in tolerances, possibly for tool wear or stock variations.  This is possible with a motion-capable PLC, but is significantly more complicated than would be the case with LCNC and G-code.  I think you'd need an input - encoder or potentiometer - driving an input that is in turn driving/adjusting the motion positions.

So at this point my vote is for an LCNC retrofit.

langdons wrote:

Really bizzare.

Try the motor sans belt, draw a notch on the pulley attached to the motor and count how many revolutions it makes.
 

Yes, I would first check if the unloaded motor is doing what it should.

What is confusing me: Is the encoder in the belt loop or is it on the motor? If the encoder is connected to the motor and the driver is matching, a closed loop system should produce an error if loosing steps. Or not? 

Are you sure the pulleys are not slipping. (do not ask me why I ask this ) 
Had a similar situation, where things went slightly off. (at first I did not notice that the pulleys were not 1:1) after correcting that it was still doing weird stuff. I started searching for an electrical problem, but finally noticed that the set screw thread on the encoder belt pulley was not cut through all the way. It felt tight but it was not, result was the encoder was counting too less.

p.s. Another encounter I had was too short step input pulses to the driver, then the driver "thinks" it needs to move e.g. 1090 steps, but the controller was pulsing 1294 times and some of the pulses (not all) were skipped.
Some drivers have settings for input pulse duration. (just an idea)

pps. Thanks to my skillful EMC design I managed to drive the Z-axis down based on spindle rpm in a random pattern.





 

Any control you choose will need to be tested, along with the IO hardware you need to use.

HAAS has user-controlled M-codes, but I've no clue about add-on IO and how they manage/control them.

Any CNC control which uses USB for IO is suspect... you need direct IO, either through a main board (of some sort) or via an ethercat drive.  Most of the hobby-type controllers I'm familiar with have the ability to control IO via M-codes, but I think this scenario is likely best suited for 'vanilla' LCNC and a Mesa board.

Researching and proving out custom IO on a commercial mill control will, I suspect, take longer than just retrofitting an existing, working machine.

Another possiblity would be to use a PLC.  I've used an Automation Direct ClickPlus PLC for a two-axis custom drilling machine and that works like a champ.  The PLC has step-dir outputs for the servos, and plenty of IO for part-present sensors and limit switches.  Programming the motion part wasn't difficult, and ladder logic is pretty easy to set up conditionals and timers for your automation sequence.

As far as suggestions for what machine to start with, I'm at a loss as I can't really picture what you're trying to accomplish.  Part size, cutting tools, tool pressure (rigidity), stock feeding and part collection... And why a mill would be preferred to a lathe.  I'm kinda picturing a lathe with an air collet closer and two live tools mounted on a gang plate (no turret).

Do you have pictures of the previous machines and what a finished part looks like?

BINGO, adding the halui line did the trick. Thank you PCW and spumco, you guys are amazing (and lighting fast responders).

After my last post I was trying "machine-is-on" in the lines WITHOUT hm2. I tried your replacement and the result is M3 and M4 no longer do anything. No error.

#net spindle1-enable => hm2_7i76e.0.stepgen.04.enable
net machine-is-on hm2_7i76e.0.stepgen.04.enable

Even tried with the same "=>" and still same behaviour.

Do I have to do something with my regular spindle hal entries for it to play nice?
net spindle-enable => hm2_7i76e.0.7i76.0.0.spinena

PCW wrote:

Simply replacing:

net spindle.1.on hm2_7i76e.0.stepgen.04.enable

with

net machine-is-on  hm2_7i76e.0.stepgen.04.enable

Should fix the issue.
 

PCW - I didn't see the halui signal machine-is-on in his HAL file; maybe I missed it.

OP - if that signal is already in your half file, do what PCW posted.

If it's not already there, you can tweak it to this:

net machine-is-on <= halui.machine.is-on
net machine-is-on => hm2_7i76e.0.stepgen.04.enable

I can confirm this fixed my stepgen spindle after PCW suggested it to me last year.

Simply replacing:

net spindle.1.on hm2_7i76e.0.stepgen.04.enable

with

net machine-is-on  hm2_7i76e.0.stepgen.04.enable

Should fix the issue.

Adding MAX_REVERSE_VELOCITY did the trick for M4 commands. Thanks.

Yes, I do have an abrupt stop with M5 $1, completely ignoring my acceleration parameters. I wonder if there would be any benefit in disabling my stepper motor driver (cheap DM542T) just as the M5 is issued. On one hand, the freewheeling could be more harmful than the coil being energized hard to stop, but on the other hand if the workpiece is delicate, freewheeling for however short of time as it can give it a better chance of survival.

If it's still a bug and 2748 is closed, is there a newer issue open? Does someone have a patch perhaps? Is this my opportunity to dive into the code? 

Thanks for the response. That's what I'm worried about, that they would do things in some weird way that will make it harder to modify. Disappointing if that's the way it is.

The thing is that I don't have time to build the hardware from scratch(base/frame/ ball screws, linear rails electrical cabinet, enclosure, door, etc.) but I do have a good budget, so I'm looking to buy a mill so I can just modify it to make my parts and get started ASAP.

I started looking at Haas, SYIL, etc. but got worried that I might be too locked out of the control to make it work the way I want. That's when I found Tormach and thought since it's based on LCNC I would have the best chance of being able to tweak anything I might need to.

So, I guess a standard LCNC install could work, but I'd still want to buy a mill of some kind. I suppose I could still buy a 1500mx or any mill really, and then install vanilla LCNC. Is that what you were suggesting?
I might keep that as a back up plan, but try to roll with pathpilot first.

Thanks for any thoughts!

So it looks like the drive is software-configurable.

I'd suggest going back to basics and connecting the drive to a Windows PC and verifying all the drive settings via the drive tuning software.

SIDE NOTE: make sure the motor's encoder count (1000/4000) matches what the drive is expecting.

Set the dip switches to 'software' (i.e. all ON). The reason is that you can (probably) set the microsteps to a useful number in software and are not limited to one of the 200/800/1600/etc values as with dip switches.

This will allow you to set the microstepping to a value that makes the steps per spindle rev a whole number, making the math for LCNC much easier.
Since LCNC's rotary axes units are set in INI [TRAJ] ANGULAR_UNITS = DEGREES, you need the [JOINT_N] STEP_SCALE to be in steps per degree.

For a 3:1 belt reduction and a 1.8deg motor, if you set the microsteps to 2400/rev (12x microsteps), you will wind up with 20 steps per spindle degree.

If you find that 12x is too fine and the positional accuracy is kinda 'ish', you can go down to 1200/rev (6x) and adjust INI to 10 steps per degree.  That might give the drive a bit more of a chance to hit a particular position rather than somewhere close-ish on either side of the target.  Either way you're still below the encoder's resolution so the drive isn't going to be totally guessing on a position.

And while you're in there, you should adjust the drive's following error tolerance.  I've found that Stepperonline's drives have a following error alarm set extremely high.  As in the motor could be 1/2 a full rotation out of position before it alarms out - not OK for CNC use.

oh sorry

No double posting, both topics merged due to attachment missing on one of the topics.