Advanced Search

Hello,

I was in touch with Luca and there was a bug in the Gcode ..  first was the tolerance(I thought I am working G21)and then was the unit system(G20) which take higher tolerance and creaty the clingy movement ... it my fault to too much truct to CAM postprocessor 

thank you for testing

In fact give this a try. Set your G64 setting to G64 P0.1 Q0.001. I think you may like the results.

If your concern is about the notchyness of the 2nd set of sign waves. I think your G64 settings are eating your lunch and your high tolerance setting is causing the naive cam detction (Q tolerance which defaults equal the P tolerance) to screw up your motion. Changing from G64P0.01 to G64P0.001 makes a big difference in the smoothness of 2nd set of sign waves and the motion ends up much closer to what your g-code was programmed to be.

 

I have been of the opinion that the current default motion planner has never been completely bug free since the circular arc blending/multi line look ahead was added back in version 2.7. I have often observed quirky behavior for series of moves similar to those you have posted. But the "new" planner offers such a significant improvement in milling speed for most cad/cam generated code as to justify tolerating it's issues.

​​​​​​​But I'm not noticing any differences between runs on my machine simulation

Have you tried running RS485 through this module? I just can't seem to get it to work.

Has this issue been resolved yet? Or has no one looked into it?

The servomotor uses the ECAC XP200 driver, and according to the manual, the digital inputs can only be controlled with 24V.

I also have the ground for the 7i92 tied to the common ground.

Now the question becomes:
will the servo drive work with 5V on the inputs?
Did you check the manual?
Older drives do not, but all new-ish ones do.
-
Now i wonder if i missed how old is your drive!

Sorry, i missed 5V/24V thing above.
I edited the above posts.

The Isolator is doing 5V to 24V translation so unless the BOB has a relay/24V output
it cannot go directly to the VFD

Sounds like maybe  grounding issue (or damaged OPTO)

Note that a parallel port ground is nearly always frame ground
but the 7I92 ground may be floating
 

Deleted as i missed the part about level shifting.
Sorry.

PCW wrote:

I would check the output of the direction control PC817 with a voltmeter/ohmmeter

I checked for continuity between the V output and GND using a multimeter, and even though the LED is lit, there is no continuity. 


Tomorrow I’ll check the resistance at the output. It’s all very strange because I have two brand-new modules, and they behave the same way. 

They always worked perfectly on a parallel port, but I no longer have the PC with a parallel port to test them again...

I would check the output of the direction control PC817 with a voltmeter/ohmmeter

What do you recommend I use instead?

Deleted as i missed the 5V to 24V level shifting mentioned above.