Advanced Search

It might also be doable with external offsets, as long as the external offsets
were set back to zero before returning to automatic mode.

(if jogging with a hand wheel in the middle of a program would work for you)
 

Yes, I read that. It would download the update but It would say 2 "not upgraded". I couldn't find a reason why. I have attempted multiple repositories in synapsis, nothing changed.

One way would be to have a hardware (or software) button that sequentially

• Un-homes the axis
• Resets the encoder to zero
• Disconnects the encoder from LCNC
• Then disables the drive 

Re-enabling it would be:

• Zero encoder
• Connect encoder to LCNC
• Enable drive
• Re-home axis/joint

This sequence should - I think - take care of the following error problem with no sudden servo movements to 'catch-up' to a massive following error.

LCNC is always disconnected/reconnected to an encoder at zero counts.

NOTE: this process would not be available while running gcode program.  i.e. no stopping in the middle of a program, manually jogging away, and then re-starting the program.

Ul wrote:

...so the servo loop is done by the mesa card.

OK, see PCW's post up.
I think with normal step/drive controlled drives it can be done by disabling the drives as the loop is not closed in LinuxCNC, but i never actually tried it.

I’m following this thread closely.But I can’t quite picture how the problem manifests itself.Could someone make a video?

Thank you. I've already tried to increase ferror in the ini file to 200mm to deactivate following error completely. I can cut off the motor drivers power supply and turn the handle, but the axis travels back automatically when reactivated. Restarting the program every time is not an option, so I will probably end up building small encoder handwheels using HEDS encoder from Aliexpress. Do handwheels at least work in MDI mode, or do I need to change the tab every time I want to operate it manually?

I am using this kind of driver from Aliexpress: de.aliexpress.com/item/1005009677397224.html
It's wired directly to the 7i92 and it drives small coreless motors with HEDS encoder, so the servo loop is done by the mesa card. No Geckos crawling in my machine.

Achso eine Ergänzung zum Bremswiederstand.
Ein Servomotor ist ein Motor und gleichzeitig ein Generator.
Versorgt du ihn mit Strom (Servodriver) läuft er los.
Nimmst du den Strom weg, trudelt er aus (Ventilator). Du willst ihn aber schnell anhalten oder positionieren. Also musst du ihn bremsen.
Hier kommt die Generator Wirkung ins Spiel.
Wenn er austrudelt, erzeugt er Strom bzw. Energie.
Leitest du jetzt die Energie über einen Wiederstand, verbrauchst du die Energie und der Motor bremst ab. Dafür ist der interne Bremswiederstand im Servodriver zuständig. Für normale Aufgaben ist er völlig ausreichend, aber bewegst du eine große Last und willst die Bremsen, erzeugtst du eine große Menge Energie.
Hier kann es passieren, dass der Wiederstand Überlastet wird. Im günstigsten Fall Verlängert sich dein Bremsweg. Im ungünstigen fall.... Hitze Defekt.
Daher wird bei größeren Anlagen hubwerken oder Fahrstuhl ein externer Bremswiederstand eingesetzt um den Motor zu bremsen und den servodriver zu schützen.


 

Good morning everyone.
I'm continuing the discussion on the Forum, on this PC; I don't have Discord.
I ran the last tests requested by Grandixximo with two versions.
Both versions, with reference clock -1 and 1, don't work well; the axes emit noise.
With the value -1, they are very present when you move browser windows; with 1, they are less noticeable but are still there.
With halscope, I monitored the profile error of joint 0 and joint 1, and when the noise occurs, you see a spike in tracking error on both axes at the same time.
I also tried changing all the EtherCAT cables with no results.
Obviously, for those who have been following the discussion, I had to reinstall the HD with Debian 10, which works fine.

I tried optimizing the GroB command, but it doesn't work.
I tried varying synclock from 0 to 300,000 and 500,000, but it doesn't work.

Now I can't stop the customer who has been very helpful.
We could try again on the next machine, in about 3 months.

The problem with the initial delay of the LCEC pins has been resolved, but the synchronization problem is still present.

I've noticed that sometimes everything seems to be fine. You open maybe four browser windows, frecad, and so on, and everything is fine. Then you reboot, and after opening the first browser window, it starts to vibrate, and it stays that way until you reboot several times.

The problem is there, and it's significant. It means we'll be stuck with Debian 10.
I imagine some drives are more tolerant than others, but we can't use a system that only works well with some drives and not with others.

Probably, if the synchronization problems between the kernel and EtherCAT aren't resolved, in my opinion, the solution would be a hardware EtherCAT master.

I want to thank Grandixximo, RoDW, and others for their efforts.
If you'd like, once I've prepared the next machine, we can meet and work directly on the machine. I'd be willing to do anything to resolve the issue.

I remain available for any clarification.

Probe Basic, after update to the "debian trixie edition", facing stopped working with a "no tool selected" error. No matter what tool i choose. Worked in the bookworm version flawlessly. 
P.s. For the installation-update, psyside6-tools (pyside6-uic) are missing and have to be installed.

 

Not a dig at all - just a tongue-in-cheek saying I found years ago.

Works better in person, since non-verbal clues (wink, wink) help both people understand how absurdly fatuous it is.

According to Mark, it is not. And let’s see how complicated it will get, but I would not attempt this if I thought I could avoid it.

spumco wrote:

The true test of someone's intelligence is how much they agree with you

I am not sure if that is agreement or a dig at me.   

Dudelbert wrote:

I thought about this a lot since yesterday and arrived at pretty much the same solution. It is nice to have that idea confirmed by you, thanks for that.

 

The true test of someone's intelligence is how much they agree with you

I bet Mark's (RotarySMP) collet closer leaks air too.  Maybe not as bad as yours, but likely needs a 'tune-up' after all these years. 

Schau mal hier
forum.linuxcnc.org/ethercat/54965-steppe...rvo?start=100#341929

I thought about this a lot since yesterday and arrived at pretty much the same solution. It is nice to have that idea confirmed by you, thanks for that.

oh and, the stuff seems to be relatively expensive.
If anyone has a project and needs a small amount (and is located in Central Europe), please give me a shout. Then I can send the rest after I am done, so it does not go to waste.

You don't have to cast the Moglice in place on the closer.  You could turn a piece of stock to the same (or slightly larger) OD, polish it, and use that as the male 'plug'.  

Could even make it solid stock with a threaded hole to use for pulling/pressing the Mogliced sleeve off.

And yes, Robin Renzetti's D-bit grinder was my inspiration, too.