Advanced Search

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.

By any chance do you mean 626VM3 ?
Is this it?
forum.linuxcnc.org/30-cnc-machines/33529-hurco-bmc-20p-retrofit
Unfortunately, i do not have access to it anymore as the shop moved.

Nice plane, looks great made out of wood.
As for machinist, i am building a styrofoam cutter to make wings for RC planes, after building some 15 drones and a single 3D printed plane that has yet to fly.
I have built several styro cutters,eve a huge 5 axis one, but his one is for me.

What do you mean by "new program to the control" ?
Do you have 2 PC's running this and the one at the machine has issues, or what exactly?
Can you do a short video and upload to youtube or google drive?

If you want, you can post a backup of your config here, and I'll take a look at.

Your Z axis limit switch is at the top of travel right?

Moved to "user exchange".
-
I am in Europe and i can speak German, but i am of no use for probing, i still did not build a proper mill. I can figure out everything for sure, but the time it would take is probably much longer than someone with experience.
Also, i never charge for helping here or whatever is initiated from here.

Japoo_Ness wrote:

From what I've measured, the issue seems to be on the encoder side.

Shielded cable, shielding grounded on the Mesa side.

Japoo_Ness wrote:

According to the diagrams, the analog signal for the axis is connected to the machine's frame/ground.

Analog cable has 2 wires plus shielding, shield must be grounded on the Mesa side, and one of those 2 wires is the analog ground.

Japoo_Ness wrote:

Is it better to isolate the analog ground from the system ground? Under what conditions is it strictly necessary to tie both grounds together?

There is no exact reference for it, see above, use a DVM to measure between analog and machine ground both in AC and DC mode > if any of those read more than a Volt or two = do not connect. If that is all correct but still does not work, you can try grounding the analog ground to machine ground through a 1K resistor for a single line, test with only a single line/analog drive/connection to mesa.
-
As a general rule, use a very good power supply for the Mesa as the encoders are powered from it.

Debian 13.7 was only released earlier this month (on 12 September) so its quite possible at this early stage that something Debian did with versions that broke LinuxCNC. Instead of complaining to all and sundry, why not raise an issue on GitHub so the devs can look at it? They are probably not aware of the issue.