Advanced Search

tristate_bit and tristate_float are the names of the hal components,
but tristate-bit.n.xxxx and tristate-float.N.xxxx are the names of the function
and hal pins that the component exports.

tristate_bit works on bits where tristate_float works on floating point numbers.

I looked at the sim config an edited a mesa config to add the new TP, but it does
show major acceleration spikes (~500K)  lasting 1 servo period. I needed to set
large  following error limits  to avoid the spike triggering a following error.

Note that this is not hardware related but may have a relation to scaling so I can try again
by modifying the sim config to make sure everything else remains the same.
 

Now taking an interest in the G10 L2/L20 pair of Gcodes.
Cannot make sense of the Documentation against the machine display.
My current job is positioned with its G54 origin having x, y, z values -ve relative to Home.

Parameters #5221, #5222, #5223 are documented as the coordinate system Offsets for G54.
The parameters in the linuxcnc.var file correctly show the G54 origin with -ve values.

But, to set up the machine correctly, I have to swap the signs used with a G10 L2.

When Gmoccapy launches, before homing, the DRO shows the tool position with +ve values.
Then G10 L2 P1 with +ve values loads the DRO with -ve values (CORRECT for this job).

Then conventional Touch-Off and run the job.

Please, is my brained screwed, or is the Documentation misleading ?

John.

Read the online documentation for V 2.9  for "homing configuration" (Several times)
the HOME_SEQUENCE parameter for each side of the gantry must be the same and it must be negative to tell Linuxcnc to treat it as a joint axis.

PCW wrote:

I can not test that as it requires EtherCat hardware.

I think you could just create a normal pncconf config for your hardware and set the ini file tpmod etc to use the scurve planner.
Once configured Linuxcnc does not care if its Ethercat or mesa.

I would imagine that it does. All the documentation suggests so and from what i can see on the other side (Its right up against a wall) It looks the same on both sides so I would wager it has them on both. So im going with yes on that.

All good, but does it have switches on each side?

I am attempting to use the hal code published by jcdammeyer towards the end of this thread but ran into something confusing.

In the beginning of his hal files he does a Loadrt mux2 but although loaded there are no addf mux2 lines AND I do not see where mux2 is used in his code anywhere.

Am I missing something here?

Well it has 2 motors and the web page mentions that it needs limits/homing switches because of the tandem setup. Each motor for the gantry also has its own cable and port. I am assuming thats what drives are.