Advanced Search

Sure. I'll try that this afternoon.

could you run in debug mode (DISPLAY = qtvcp -d qtdragon), run linuxcnc from a terminal and post the output?

You are correct but in my case the servo isn't connected to the axis, and only spins when the +-10V are connected to the 7i77, if unplugged the servo is perfectly still.
The exact same setup for the Z axis works.
I'll check the axis configuration today, maybe I made a mistake.

I need 2.9 because I want Probe Basic, and it won't run on 2.8 for me..

My FT sensor is a multiple-axis sensor that mounts at the robot end-effector. Tool gravity compensation, external force, and new joint position command calculation are already done, so right now I need to send these commands to LinuxCNC.
Sending via the jog command does not give me a smooth move, I will try the jogwheel function by converting the position command to jog count, not sure if it works

Lately I started looking with great curiosity into LinuxCNC, because it seems to be one of the nicest and most affordable options to get EtherCAT and recently even s-curve acceleration control! In other words, as far as I know, it's the only solution on the market that offers such badass features as well as full configurability at a fraction of the price of other devices.
My current experience is with Mach 3 and UCCNC, but in both cases I was dissatisfied with motion planning where the machine would stutter a lot with complex toolpaths or with larger error allowance, it would run smoothly but it would mess with the surface finish.

My biggest hurdle right now is finding the right hardware. I saw countless solutions and configurations to get this done and I'm looking for something well proven that's not too hard to set up and doesn't look like spaghetti.
I was looking into Mesa boards, but even that got me a bit confused and I don't know what I should get. What's important for me is that the board offers screw terminals for interfacing with endstops and VFD and ideally it has its own computer - i.e. Raspberry Pi.
Could I ask someone for some recommendations? 

I've set up a few multi head gantry machines, but the ones I was working with had fixed spacing between the heads. I've set them up using Z and W for axis for two head machines. But for a larger machine I set up that used 8 heads I used the new extra joints feature and controlled them all with the Z axis command, with each joint having separate offsets for tool lengths and the ability to enable/disable each spindle/head and when one was disabled it automatically would park raised up at it's home position.

I've thought about dual head machines with two heads on a common X or Y axis a little bit and can imagine couple of ways to handle it. One possible way that I think has merit would be to configure both heads with a common X with a U axis set up as the spacing between the two heads. This way an X axis command would move both heads in parralel motion, and U commands would vary the space between them. To set up this, if the joint arrangement is such that the two axis joints are totally independent (say each head is driven by motor turning a pinion gear on a common rack on the gantry.) the kinematics model would be joint0 = X position, and joint3 = X+U and revers kins X=J0 and U=J3-J0.

The advantage to this set up would be that the g code for milling out 2 parallel identical parts could be simple 3 axis xyz g-code. (This could be a big advantage if the current version of Linuxcnc still doesn't do advanced look-ahead tool planning for axis beyond XYZ especially if UVW are left out. That used to be the case a few years ago but may no longer be true and was the reason I set up my machines the way I did to allow commanding multiple Z axis with just a Z command instead of using Z and W...

But If you would want to do something different with both heads simultaneously, like for example cutting out mirror images of the same shape at the same time one on XYZ and the other on UYW. Then it would probably be better to have simple 1:1 kinematics with J0=X, J1=Y, J2=Z, J3=U, and J4=W. However this will make collision prevention more difficult than the U=J0+J3 model.

Why do you need 2.9?

I though you just wanted to try a different GUI.

Also, there is a reason AXIS is the default GUI.

It might not be perfect, or flashy, but it's pretty good.

Don't mess with BIOS settings unless you really know what you are doing.

Default values are usually the default for a reason.

(Sometimes the reason is stupid, but ususally not)

Setting the cooling profile to "performance" or "active" is always a good idea though.

Whoa!

That';s not what I meant.

The CPU fan profile to "performance" or whatever seems like the highest speed.

 
Different python versions probably work fine.

But APT and LinuxCNC, and GNU/Linux don't understand that.

Would a virtualenv work or something?

Stupid Python.

I wish Python had LTS releases like Java does.

i have actually learned quite a bit from this project to be honest. i have some big plans for this build. a conventional table and a rotary cutter have some very different needs, if all you need is to cut round tube then things can be kept fairly simple, but if you cross over into other profiles things can get quite involved. this project is one of those projects that take forever to get finished but once done you have something substantial.

I understand, but the file you posted is .HEX and not BIT, so to use it, as I understand it, you must use a PIC programmer. My question is: how is this procedure done?

Thanks Henk,

super useful!

Is the index Z pulse that you mention the R/-R signal on this table?

www.ditron-dro.com/product/ditron-high-p...g-machine-dro-tools/

Could you set it up as a probing move using the force torque sensor target value as the limit input for the probe input? Possibly using a comp hal component to compare the FT sensor output with the desired value.

(edit)
The tricky part would be if you would have to listen to the FT feedback from multiple FT sensors on multiple axis for a complex multi axis kinematic move. But if you only need to listen to one sensor on the end effector, or limit moves to single axis moves, the above should work. (I think)