Advanced Search

I am not much help with probing nor QtDragon, for the rest probably yes.
As for video call, yes of course, now is OK for me as i am going in the shop, i have whatssapp only, but there are some general rules to follow:
-if something is unclear, ask again and again, there are always more than one way to describe something
-when using chat, read all the replies, not just the last one, so scroll before asking or doing anything
-follow instructions strictly
+38349137704
will be available for the next hour, after that leave a message and i will get back, as i do not keep that phone with me all the time.
-
Will delete the number after confirmation you got it.
And you owe me a coffee whenever i come to Germany!

Dear everyone, i have posted about my cnc issues and am kindly asking for help here   but i think this may become harder to find then i thought. Any tips if there is consulting help or physical help and an option, please do not hesitate. I am happy to spend a dime. 

BUT i am preparing myself for a week of CNC evenings and nights as this is ultra urgent to fix for me and my small shop. 

I am using a mesa MESA 7I76EU STEP/IO STEP DIR plus I/O controller card on my CNC. its about 1.5m X 1.2m with 35cm Z axis travel distance. 
Sadly i was not able to perform the full retrofit fully myself due to time constraints. I did though the complete electronics overhaul. 
I have added a new tool length sensor and a 3d probe. 

From my cnc workflow so far i have this process in mind and I would love your take on it. I have used multiple CAD / CAM solutions in the past, the longest i have used fusion360 and right now im trying out onshape cam. 
But in general the workflow was the same:

1. CAD design the part
2. In Cam I am creating a setup
3. I create and define stock (if necessary)
4. or I set up the part reference point 
5. that defines the WCS XYZ 
6. This allows the postprocessor to generate toolpaths.
7. Using the postprocessor to output G-code
8. I load whatever CNC program (right now linux CNC QT Dragon)
9. I home the machine (if necessary) 
10. This sets G53
11. Then I either do this: 
12.  A) I insert Tool 1, measure tool 1 at the tool lenght sensor. G43 H1 mit Z20 z.b. . Then I take my tool length sensor, place it on top of the material. I am zeroing Z-height (G54 Z = new coordinate - tool length sensor dimension)) and i place the machine head roughly where i want to cut
13. I take a 3D probe, probe the stock or piece or reference that i need. I align the WCS to it. (if the probe needs calibration, i probe the table or a defined height of a pin right next to the tool length measure.) This sets G54 XYZ. Then I insert Tool 1 and measure tool length on my tool length sensor. G43 H1....
14. Run
15. Tool change
16. Measure T2 G43 H2 is stored
17. continue and repeat

BUT it seems that in our setup of linux this process does not work at all. I am getting homing error and out of probe errors the moment i am doing the basic qt dragon features for probing and sensing. 

 































 

Sorry my edit was left in draft mode and did not got posted.

No no actually its good. I think I am looking into two avenues. Either i fix it myself but completely redo the setup or i find help and am happy, very happy, to provide some financing for next cnc project to someone. I need the machine basically and the bodged retrofit or rather not completed retrofit is killing hours.

If you or anyone would be open to jump on a video call or something. I think most of you here would probably spot the issue instantly.

Avion wrote:

darm, the mods have moved the topic to the dark corner of the forum

I did that as noted above:

tommylight wrote:

Moved to "user exchange".

If you think it would help, i can move it to QtVCP section, but we tend to keep anything involving payment here.

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?

Glad they figured it out so quickly. Classic case of tweaking the ini limits on a fresh setup, happens to the best of us.

    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.