Honestly it sounds like you should be using a Darlington OPTO in place
of the low CTR PC817, say a LTV-815 or similar.

( PC817 mas a minimum CTR of 50% vs the LTV-815's 600% minimum )

Yes! that is a win, especially if combined with the new G28 that allows rehoming
a single axis. That would really simplify combined axis/spindle operations.

Alright, bit of progress. I did some testing and managed to get the PC817 module working — at least for now.

The module has a 302Ω resistor on both the input and output side. When the LED turned on, the output voltage only dropped to about 21V, so the servo driver wasn't seeing it as a proper low signal.

I tried putting another resistor in parallel with the one already on the output side, and bingo — reverse works. With a 3k resistor in parallel, the output drops to around 14V. With a 1.5k, it drops to about 10V. Both values make the servo reverse properly.

So my question now is, what's a safe resistor value to leave in there permanently? I don't want to damage anything, but I need it to work reliably. What would you guys recommend?

Hallo timo,

vielen Dank für Deine Info. Ich habe die Endschalter auch in der ini abgeschatet.,

nach Anweisung von ACIERA..

Damit kann ich erst mal arbeiten.

viele Grüße Karlhe

I am in need of some help. In mb2hal.ini transaction 02, I can not get the set speed working. The crash message states that " mb2hal.spindle-set-speed does not exist ". I have stated it in the custom_postgui.hal file. I am wanting to have the " run speed slider " populate the set speed parameter in the drive.
Transactions 00 and 01 work fine

Any ideas would be appreciated.

image missing /media/kunena/emoticons/smile.png freue mich! Es lebt wieder!  Es geht weiter mit NativeCam.  NativeCAM 2.0b – Python 3- und GTK3-Portierung für LinuxCNC 2.9 / Debian 13 Trixie
NativeCAM
Damit wird Linuxcnc zu einer Steuerungssoftware mit Inkludiertem CAM... ja nicht ganz, aber fast.
Ich würde es eher Prototypen Teile Fertigungssteuerung nennen. Ähnlich der ProtoTrak oder Heidenhein-Dialog oder so.

Möcht auf die schnelle eine Rechtecktasche Fräsen und dafür nicht den CAD Rechner anstupsen. Auch nicht von Hand G-Code schreiben.
Das geht mit NativeCam!

Was denkt Ihr dazu?
Braucht Ihr das?

@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