Advanced Search

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.

Does the machine have two motors and two drives for the gantry?
Does it also have at least one limit switch on each side? If not, do not bother with setting tandem joints, it does not work without a switch for each side.
Need an answer before i go off typing all the possibilities...

I recently updated from LCNC 2.7 to 2.9.4 and am in the process of tweaking my old hal file to be compatible with the newer 2.7 version.   I am also forced to redo the code for my shuttlexpress because the component (HIDCOMP) that I previously used is no longer valid.

  My old hal file had the component tristate-bit used in it   (minus sign).   The current hal component list does not even list tristate-bit with the minus sign BUT does list a tristate_bit with the underscore character.    Interestingly, my present hal with the minus sign seems to operate and not throw any errors under 2.9.4.      Is the old syntax with the minus sign still supported in 2.9.4?

THEN.....    I am adding a shuttle jog component.   The published hal file for the shuttle uses the  Tristate_float component.    From the hal component manual descriptions tristate_bit and tristate_float seem to have identical functional descriptions with slightly different syntax !!     I am confused why both exist if they are the same ????       

THEN.......... my real concern is if I use all 3 versions of tristate,    Tristate-bit, tristate_bit and tristate_float in the same hal file if it will cause a duplicate error crash/fault?      I would guess not considering all 3 have unique names /syntax but would sure like someone to confirm.

This is quite confusing.

Thanks,
George

 

Where is the arc ok derived from? Plasma? Reed switch? or from THCAD?
For first two, check the plasma source, not LinuxCNC/Mesa/THCAD

I have spent quite a while trying to get one of our older CNC's to run again. I had a lot of issues with getting the gantry properly setup and I heard that 2.9.4 has support for tandem motor pin outs so I downloaded it and I have managed to get the gantry to move. The problem is that if i'm in the test axis in stepconf only 1 motor moves and in the actual jog interface the motors are separate joints so if I jog the gantry then I have to jog joint 1 and then joint 2 instead of pressing one button. As a result I move it incredibly slowly to avoid skewing it as much as possible. I would imagine I did something wrong or that their is some way to combine the two joints too run at the same time? would I need to do this in the HAL or INI files?. My other question is about how i'm supposed to setup the limits because I have just been setting up as: both limit X, both limit Y, and the same for the other two motors. I did get an error about limits on one of the Y's  but it didn't say much other than something along the lines of "Error limits Joint 2"
www.probotix.com/CNC-ROUTERS/CNC-ROUTER-GX2525 Here is the machine (It only says Comet on it but I am very sure this the same one)
www.probotix.com/wiki/index.php/Unity_Controller  Here is the controller its using as the old one had some fried chips that couldn't be replaced. It also has the pin outs where I got the limits from.
Sorry if I it's something obvious because I really haven't used linuxCNC ever before (Also disclaimer: I haven't set the latency test right yet because I only got it working in a test setup yesterday and I didn't have time for it but I know I need to do it)
 

Thanks Tommy,

Here now trying to fix it.

First cut is fine. Second cut won’t create an arc ok. Everything off including thc.

Light on the Mesa goes the first time, but second time halshow and hardware all show that arc ok doesn’t change and the input on the Mesa board doesn’t change.

I've been a little quite online lately. Been busy working on the STM32H7xx version of Remora with a lot of refactoring and hardware abstraction in preparation for the next steps to a common code base. I've also managed to get PlatformIO up and running for development and debugging. Important to be able to support multiple boards.

For those interested, the testing repo is:https://github.com/scottalford75/Remora-STM32H7xx-PIO

Inspired by the great work done by Sean McCully, github.com/seanmccully , the Remora code base has been significantly been reworked:

Remora is now a class of it's own
Communication is now handled via a comms handler, with hardware abstraction via a CommsInterface class
Hardware agnostic by creating hardware specific classes in main and then passing them over to the Remora constructor

The next steps....
Setup a organisation repo for Remora. We need a repo name as Remora is already taken
Setup the core Remora repo
Test the submodule approach with the STM32H7 work to date
Test with STM32F4 etc

BTW, TMC5160 support is working in the H7 testing repo so were not too far off having this across other boards as well.

cmorley wrote:

Excellent!
Cool colors too by the way!

I was just about to say the same thing.

Excellent!
Cool colors too by the way!