Advanced Search

@grandixximo -

That would be a huge win if your fix works.

Now, if you can figure out the non-deterministic threading/tapping...

github.com/LinuxCNC/linuxcnc/issues/3455

Hallo zusammen,
ich hab den Fehler gemacht und mir so eine F7198 in der Version 1.1 geholt, auslesen kann ich sie, aber da muss ein Bitfile drauf.. Aktuell sind alles nur ein oder Ausgänge.. DerVerkäufer hat mir auch einen baidu-Link geschickt, aber ich bekomme die Files einfach nicht runtergeladen, vielleicht liegt auch an meinen fehlenden Chinsischkenntnissen? kann mir dabei einer helfen oder die Bitfiles für die F7198 V1.1 zur Verfügung stellen?  Vielen Dank schonmal! Gruß, Thomas

I think I might have the fix
github.com/LinuxCNC/linuxcnc/pull/4200

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...