Advanced Search

Yes.

darm, the mods have moved the topic to the dark corner of the forum ...  
Just kidding. @tommylight, would you be open for a call? 

I am diving int the cnc setup again and need to fix the processes. I am getting errors constantly wheras it should be a normal operation. 
I will post a detailled process question later today
 

Hello folks

Very good news: The MAHO mill retrofit has entered the finishing state. 
LinuxCNC can now read all inputs, sensors, thermal-switches, ... and also control everything, from the gearbox-motors, the VFD with the spindle motor, the Indramat DC motor driver and all the other components.

Features working at the moment:
- Working DC axis motors (PID not tuned)
- Reading the Heidenhain LS403 glass scales directly with modified EL5021 terminals
- Working gearbox and VFD (EL7332 controlling gearbox motors, Danfoss FC302 controlling original spindle motor)
- Working toolclamp-mechanism (with added button)
- Safety related inputs handled with TwinSafe Safety Hardware (EK1914 and EL1918)
- BusCheck monitors EtherCAT bus config (SafetyPLC CRC now too)
- Faulthandler gives operator detailed info, warning and alarm messages (message conditions need to be cleaned up)

The best feature probably is the continuously adjustable spindle speed. When a speed between 8 and 4400 RPM is requested, the best suited gear of the gearbox is selected (and will be used for all further requested speeds until a M5 command is sent) and the last speed adjustments are done by setting the spindle motor speed accordingly. That way it should be possible to cut threads with rigid tapping in theory up to 260 Nm in the lowest gear. A video of the three LinuxCNC spindle related components (fc302VFD, gearbox and spindle_master) working together  is over on YouTube .

Beckhoff has their own way of implementing a zero logic for their encoder terminals - for the Z(ero)/reference impulse. There is now also a component, which ties this index zero logic into the LinuxCNC homing logic. The component should work with all Beckhoff encoder input terminals and boxes - it was only tested with an EL5021 terminal. All components and the whole machine config can also be found over on github .

There are still quite some things that need to be done, like tuning the PID controllers, designing and building the new monitor-arm and so on... But we are getting there

Hey Tommy.. thanks for the offer. I am really looking for someone who is willing to take the deep dive . The language is not the issue, the physical locale rather. I was thinking maybe its good if the one could come over.

can we control servo motors and drives in linux cnc

hermann1976 wrote:

I still haven't found the source of my error.
 

I am sure that the reason for your error lies solely in your settings.
NativeCAM performs implicit operations, so the result may be surprising, although formally correct.
I managed to achieve this effect:
 
I did it by entering an absurd offset in G54.
NativeCAM clearly copied it to G59.3, and then tried to perform some operation and went outside the working space.
It may be more subtle for you, but it probably works the same.
 
Thank you for the tip with G59.3.
Of course, G54-G59.3 are basically there to execute the same program in absolute coordinates in a different place in the workspace. Expect codes G55, G56, etc. to be used sequentially as needed. Of course, you can reserve one of them for something and not use it for anything else, but it should be the last available code and not a random one...
In Gmoccapy you can even add an appropriate comment to the offset table, as seen above.
It's always better than ruining the G57...

Hello tuxcnc,

Many thanks for your feedback and your willingness to help me with my problem.

I can certainly understand your concerns.

I believe a clear approach is necessary. However, i think it is common practice to switch from one coordinate system—such as G54—to another during a program's execution. This offers many advantages.
I wrote a dovetail milling program (independently of NativCAM) that is variable; it automatically calculates the dovetails based on the varying widths and components of a drawer—sides, front and back pieces, etc.—and mills them accordingly.
The individual dovetails are milled within a loop where the coordinates remain relative to the same reference point. After one dovetail is cut, the G59.3 coordinate system is shifted, and the loop runs again. This continues until the entire row is finished. This keeps the G-code compact and manageable.
The situation is similar with NativCAM.
It just needs to be clearly communicated that G59.3 must not be used as a general workpiece zero point, but is reserved specifically for NativCAM.
You can set your preference in the settings (see attached image).
It is also important to include G54 in the initialization settings (see attached image).
This ensures that the system switches back to G54 after the program runs, and selects G54 again upon restarting after an interruption, thereby restoring the initial state.
Unfortunately, I was unable to trace or reproduce the error you described. Whenever I ran a program, the result was always consistent.

Thanks again for your help.
I still haven't found the source of my error.

(tranlated with GoogleTranslate)

Then, I need to connect the shielding for the encoder signals and the driver signals. Is it okay to connect the chassis from the 7I97T to a bus bar with these shields, or is it better another way?

I also want to ask: doesn't this keep this ground somewhat floating, since it doesn't have a discharge path, or am I wrong? Or when you mean ground, do you mean power ground?

    I will have to see what it comes out to with tarrifs in the US (Thanks to the current administration ).
I will most likely get at least one.

Ordered mine Sunday. Thanks PCW. Looking forward to it's arrival.

I mean the MV3C. The “C” stands for “compact”; it's a smaller model and is only available in 200V. The MV3 is available in both 200V and 400V.

User hermann1976 in the thread forum.linuxcnc.org/nativecam/59280-nativ...-transfer-to-control described strange behavior of LinuxCNC after generating a program with NativeCAM.
Partly out of desire to help, and partly out of curiosity, I started digging into the topic...
Although I wasn't able to reproduce the error described, but I found something much more important...

Well, there are no miracles in IT.
It is not possible for the same program to work correctly sometimes and then interrupt its operation by reporting an error.
Damage to the computer had to be ruled out because the error was repeatable and could not be due to random causes.
Since the reported error concerned going beyond the machine's working space, the first suspect was the offset subsystem.
And in fact, my default coordinate system is G54, and after running ncam.ngc it switched to G57 to return to G54 after finishing or interrupting.
This is so important that the operator may not notice it at all.
Although I didn't find G57 in ncam.ngc, there is a line #<_off_rot_coord_system>=57 (I removed the spaces). In turn, in the subroutines called from ncam.ngc there are lines G#<_off_rot_coord_system>, so it is it.
I didn't look any further in the code, I just decided to check if it was possible to take the program outside the working space by entering absurd offsets.

And this is where I really got scared.

Well, ncam.ngc overwrites the offset table !
He simply treats global data as his own private data.
After finishing the operation, it does not restore the previous data (which would not work anyway if the program was interrupted), it just leaves its garbage.

If the operator now executes another program that is using G57 that has executed correctly hundreds or thousands of times, he or she will get an unpleasant surprise, because the machine will work in other place than expected.

This is simply dangerous and therefore unacceptable.

No, i mean when i push the Button on the left upper corner in NativCAM then the Programm will load autmomaticly in linuxcnc in program drive.
The video:

Ok much appreciated here is my current hal and ini files 
   
And yes my z axis home/limit is at the top of travel.

I would first check the encoders, the thin slotted disk sometimes rusts and keeps getting worse with time.
You can check the Granite Devices, i did use Argon drives and they are quite versatile, but knowing how much time it takes, i would just go for the cheap china drives with motors.