Advanced Search

G93 is fine.

I just wanted to post a little update - I got to the point where lcec HAL pins reflect parameters saved in VFD drive (min and max velocity) which makes me think that EtherCAT communiction is actually working, but I cannot get the VFD to switch its modes. I was switching cia402.enable pin on and off, controlword value was changing (I had connected cia402.controlword with lcec.0.[some_more_symbols].controlword) but lcec mode pins never changed their value.
On the nameplate of VFD among all the numbers etc there is a letter which according to manual means that the drive was preconfigured when ordering for some (unknown to me) addon module. And drive shows error A7AB which means that the drive does not find the module it has been configured for. And since that is a second-hand drive I have no way of finding out more.
Long story short - I gave up on my attempts to get this drive to work with EtherCAT and already told that to my customer.
Rod thank you for your time and effort helping me on this one!

grandixximo wrote:

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` 

This is a very bad idea, looks like it was captured from Mach3...
This is what LinuxCNC is good at, it doesn't have a thousand buttons that change the way it interprets g-codes.
Sharing settings between the ini file and the ngc file like this is bound to end in an accident at some point.
However, there are no contraindications to adding a new G or M code that will do what you write about. Then everything will be in one file and there will be no risk of running one program with the settings of another...

No problem, just trying to give a little back!

Maybe it was a limit error, but the message did not help figuring that out at all, was the sub itself that was out of limit? and it caused the error in the picture?

I'm deciding whether to work on a LinuxCNC feature and would like to know first whether anyone would actually use it.

Today, when a rotary axis moves together with X, Y or Z, F applies to the linear axes only, and a rotary move on its own runs at F in degrees per minute. On a 4th-axis wrap, where the surface of a cylinder is cut with X and A, the surface speed therefore doesn't match F. The usual workaround is inverse time (G93) from the CAM.

The idea is a reference radius for each rotary axis, set in the INI. For example, `[AXIS_A] FEED_RADIUS = 25` puts A in the feed calculation as if it were a length at 25 mm from its centre. A move of A alone at F100 would then run at 100 mm/min on the surface at that radius, and X with A would run at F along the combined path. Siemens (FGREF) and Fanuc (a parameter) do the same.

Questions:
1. Would you use this, or does G93 from your CAM already cover it for you?
2. What machine: 4th-axis wrap, rotary table, something else?
3. The useful radius is usually the stock radius, which changes per job. Is a fixed INI value good enough, or would you need to set it from G-code?

A short "yes, I'd use it", "no" or "G93 is fine" helps. If nobody needs it, I'll leave it.

 

@plasmanfm

1.0.7 will release today and the help file fix is in.

I received the braking resistor yesterday and mounted it on the left side of the cabinet. The cables that came with it were just long enough to reach all the way to the spindle drive.

 

 

With the braking resistor installed and the parameters set in the spindle drive the faults when stopping the spindle from high RPM disappeared.

As the machine seemed to be ready for the first test cuts I cleaned the vices in the parts cleaner and installed them.

 

Getting all three of them trammed in took it's time as usual...

 

For the first nervous test cuts with the new spindle I used a piece of 7075 aluminum.

I started with an 80 mm face mill and immediately noticed a clear improvement in surface finish which I hadn't expected.

 

Next I milled the sides with a 16mm DLC coated solid end mill. The resulting finish was something I've never seen on this machine before.



This was just a quick cut with a width of 0,5 mm so this feels very promising. I'll report back when I've milled a few real parts.

All shielding should be wired to a terminal block to machine ground.
Search for HyperTherm grounding best practices, they had a very good pdf about it.
And since we are here, grounding and shielding is never simple, so requires a bit of time, but it is very well worth it for the time it saves when working with such machines.

Got myself one. I will add it to my collection of backup ISO's

I managed to get it working. Here are the files.

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.