Advanced Search

Hi Aciera,

thank for the input. Today I started to configure vismach, when i realized that my TCP moves seem off by quite a bit. Which leads me to the following questions:

With the Mazak Z axis is lying horizontal and X standing vertically. -> So i switched X and Z in my vismach model and everything's fine. But in TCP i realized that if i switch between normal and TCP my Z axis was moving left and right. Which had to do with the X/Y offsets for TCP. Witch made me lead to the conclusion, that in the TCP calculation the tool-offset need to be applied to X and not Z. Which than begs the question if the formulas for X and Z need to be switched completely.

So i started doubting everything and searched the forum. I found your XYZBC-TNR example which sadly i can't run right now because of some permission problems:

But I'm still not quite sold if i can copy the the TCP math from this example. With the Mazak the head is swiveling around Y (B-axis) in your example it's a dual table config.

I would be real glad if you could give me some input on:

- 5 - axis Kinematic with swiveling B axis head
- The X and Z axis switch debacle
 

Hi,

Using the linuxcnc iso & ethercat my jog speed is max 5000 mm/min. and apptime 50000.
This is tested on a laptop. Very bad performance.

I used to have apptime 15000 and jog speed around 19000 mm/min using a desktop pc.
 

It's the same screen. Jim's original name was silverdragon. When I incorporated it into linuxcnc, I renamed it in the code. We just got used to calling it qtdragon so in 2.9 I went with it.

Jim also has a newer version in github.

notJamesLee wrote:

Friends,

from what I can only assume is inconsistencies in diameter or something but 533.33 is the number.

with 533 after 20+ revolutions you can see the starting point creep earlier -- indicating its just short of the number of steps to complete a full circle.

with 534 after 20+ it goes the opposite way.

I have a few follow up questions:

- what should i have the dip switches set to? Now that we've figured out they don't do anything to effect the steps per revolution is there an optimal value for this? I dont need insane amounts of torque or rpms

- is this something i can easily fix with the encoder once i do move to LCNC and tune in the encoder error?

thanks all for sanity checking me thus far, nice to know im not 100% crazy.

Sounds like you're still struggling with the driver, yes?

Maybe I missed it, but what brand/model driver do you have?  Asking because some drivers can be tuned via software (in addition to dip switches), and there may be a setting (or another dip) that disables the external dip switches.

No need to apologize, war is hell.

If I see it correctly it has a LPT port?
There are different version I see now. So it has 7 input pins (GPI) and 7 output pins (GPO).
With a XYZ machine you'll have just enough output pins to control the steppers, but like PCW said you'll need to create a driver for it.
If you could still return it, the one with a LPT port might be a better choice. If you want to be more sure that it will work reliable with a fast rate a hardware controller will be a better choice.

Fair enough. Perhaps when it’s ready for prime time, we can work through the other issues to come up with a cohesive solution and find a way to push the project as a whole forward.

I prefer to be positively realistic

Keep up the nice work!

Yes you should switch. At least try it.