Advanced Search

Open the post processor in a text editor. There are some settings you can change which allows QTplasmac to be the master of cut settings.
There is a script included that converts a Sheetcam tool file to QTplasmac format.

Some of this rubbish is because a company engages a IP lawyer and the lawyer fires off all of these unsubstantiated ambit claims so he can bill his customer.

I don't think a hardware master could be used with Linuxcnc in the present implementation of Ethercat. Choose this option carefully as it might require replatforming.

Since the VFDs outputs are sinking you would connect (for example):

PIN 41 --> 24V common

PIN 39 (ORE)    --> 7I97T INPUT8 (TB5 PIN 1)
PIN 35 (NDET)  --> 7I97T INPUT9 (TB5 PIN 2)

+24V --> 7I97T INCOM 8,9 (TB5 PIN 3)

Be very careful that you do not accidentally connect +24V to
any VFD output, as that will instantly destroy the VFDs optocoupler.

Hello everyone,
over the past few weeks we have been able to fix several bugs—mostly in the software—so that the machine is now ready for milling, even without the tool changer.
We are currently working on the tool changer and have been able to learn a great deal from the LinuxCNC documentation and successfully implement what we’ve learned.

Right now, the Yaskawa spindle inverter is giving me a bit of a headache. Perhaps there is someone here who can tell me how to connect the output signals—as shown in the pictures—within the Mesa card.
As an example: the spindle orientation function uses signal contact 39, while contact 41 serves as the common (COM). As soon as I initiate the spindle orientation and the process is complete, the VFD outputs the signal via contact 39. To verify this, I can see on the VFD's display that the signal is being generated internally; however, I am having trouble reading this signal with the Mesa card.

Another example would be speed detection. How is the signal processed?

What is the difference between Signal 34 and 35?

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.