Advanced Search

Since I was last asking for assistance, I opted to switch over to a 7I96s board. I am having issues getting a cheap MPG pendant to jog axes in the Axis GUI. I have confirmed that the encoder works as well as the dead-man switch allows the signals I've designated as axis selectors and step values to trigger appropriately. I have seen forum posts about joint vs axis jog being toggled through the use of homing. (joint vs teleop) I utilize the Home all button to zero out the display before attempting to jog any axis. Using Halshow, I am able to see the joint-select-(a-d) and joint-incr-(a-d) trigger as well as the axis-selected-count value count up and down. I used the PNC wizard to setup the pinouts and didn't see "Axis select" as an option but did have "Joint select" available. I assume, based on what I've read about the 2.9 update that this wouldn't be an issue as I'm just using a standard 3 axis cartesian XYZ setup with possible expansion to XYZA once I have more confidence in using Linux CNC to actually run my machine.
It's probably something overly simple like linking joints to axes in a different way than PNC did by default or just a need to add a switch to convince the machine that it's been homed.
I've attached the Hal and Ini files for review.

I am running LinuxCNC 2.9.4 from the official repository, but it seems that modbus functions 1 and 5 aren't available. (loading my partial mb2hal config file at halrun throws "[fnct_05_write_single_coil] out of range") I read that Linuxcnc 2.8 didn't support those functions, but that 2.9 should. What am I missing?

I've gone back to 2.9.4 because of a similar problem with 2.9.5/6.
At first all buttons on the pendant work fine until I try to call an MDI_COMMAND_xx. The command itself is not executed but afterward there is a zombie process and most of the buttons on the pendant stop working. In halshow all buttons and connected signals still show activity - even MDI_COMMAND_xx are getting called - but nothing happens. After restarting linuxcnc everything ist back to normal. With 2.9.4 this does not happen! Seems like something is wrong in 2.9.5/6...

I have been fighting these iX7NH drives for several days and they still won't reliably communicate via ethercat. However, they talk ModbusTCP just fine. What's the best way to control axis drives via ModbusTCP? The machine being driven is a pallet changer for a milling machine, so path accuracy doesn't matter, only endpoint repeatability. I figure it won't matter that I can't have CSP mode.

In order to make the drive move the motor, I have to:

1. Set coil 0x12 == 1 (SV_ON: This enables the drive output)
2. Specify movement speed (register 0x6034), acceleration (register 0x6036), and deceleration (0x6038)
3. Specify the target position (register 0x6025)
4. Set the control word (register 0x6001) to 0x30, then immediately to 0x20 (I tried this without linuxCNC, in Python, with no delay between the statements, and the servo system executed the move correctly)

Step 1 only has to happen once, step 2 whenever the application requires it, and steps 3/4 whenever a movement must happen.
It seems that I could use MB2HAL to create HAL pins for coil 0x12, registers 0x6034, 0x6036, 0x6038, and 0x6025, and data from LinuxCNC's motion planner would sail right through to the drives, but what about the control word register?
I have to set and then clear bit 5 whenever I want the drives to make a movement.

You're welcome, I'm glad you got it worked out. On the topic of separate machines, the logic is there and holds water; it's almost like multiprocess welders, unless you drop some serious money, you're compromising. And I, for one reason or another in the past, needed both couldn't afford both, or didnt have the space, I know I'm basically handicapping the machine, whichever gui is loaded but not ot the point, parts are out spec, or customers bringing stuff back. The plan is to build another machine for a 3 to 5k fiber laser, ditch the plasma altogether, and mount an ATC spindle and vacuum holding to this current one. I've been really good this year, hopefully a smoking deal comes through on BidSpotter for a laser source. This is the 5th iteration of a CNC gantry-style machine I've built. I went HAM on it just because I'm tired of being tired of not being satisfied with it.  The .5" flat bar on top has a reference shoulder machined in and a skimmed on both sides im gonna use jack screws every 12" or so in pairs to get this thing as coplanar, square and level as pyhics will allow, me to and then use a metalized epoxy to bed the bar to the frame and finaly a few stitch welds to lock it in.  ce la vie i gues. Your set up is pretty gangster 

 

Hello, what is the content of toplevel.py?

import oword
import remap

FF0 should be 0

Thanks for reply..so I just need to lookup how to configure as spindle...no wiring...speed controlled by gcode?...motor driver would need parameters changed or can that be done through linuxcnc?

Thanks again!!

The problem is that you can not reuse a hal pin anywhere in that hal file or another hal file. However you can connect multiple hal input pins to a hal signal name (but only one hal output pin).

Not seeing what you have going on in your other hal files I think this might get you going change this line in your post gui hal file from:
net tool-change gmoccapy.toolchange-change <= iocontrol.0.tool-change
to:
net tool-change-request iocontrol.0.tool-change

That may still not get your config working, if you have other similar mistakes in your postgui hal file. But it will get you on to the next one.

Hi need some advice I tried to do this much as possible on my own but ran into a error not sure whats the best way to get around it.Looks like i have two pins for tool change ? 

For one, thing the "Calibration" window will not show that as a tune-able option in the calibration window.

I'm not sure that you can do that within a single Linuxcnc configuration, but you can set up 2 separate configs, one using the servo as a 4th axis and a separate one where it is configured as a lathe spindle. Both configs could reside in the same config directory and share most of the config hal files. They would need to have their own ini file though.

Is there any reason to set the values for pins / parameters in the INI vs. the HAL?  Is using the INI simply a best practice? 

For example, this line are in the HAL file:

          setp pid.u.Pgain                            [JOINT_4]P

and this in in the INI file

          P                    = 1000.0

I assume I could set this value in the HAL file without using the INI file:

          setp pid.u.Pgain                            1000.0

 

ACTIONS TAKEN:
I re-added these lines to the HAL file:

setp pid.u.Pgain                            [JOINT_4]P
setp pid.u.Igain                            [JOINT_4]I
setp pid.u.Dgain                            [JOINT_4]D
setp pid.u.bias                             [JOINT_4]BIAS
setp pid.u.FF0                              [JOINT_4]FF0
setp pid.u.FF1                              [JOINT_4]FF1
setp pid.u.FF2                              [JOINT_4]FF2
setp pid.u.deadband                         [JOINT_4]DEADBAND
setp pid.u.maxoutput                        [JOINT_4]MAX_OUTPUT

and these to the INI file

BIAS                 = 0.0
DEADBAND             = 0.00005
MAX_OUTPUT           = 10.0
OUTPUT_SCALE         = 1.000
OUTPUT_OFFSET         = 0.000
P                    = 1000.0
I                    = 0.0
D                    = 0.0
FF0                  = 1.0
FF1                  = 1.0
FF2                  = 0.0

RESULTS:
That seems to have fixed the speed problem I was having. However, a new problem has now arisen:  When I initiate the move, either by jogging (e.g., 0.1") or using the Gcode (e.g., G0 u-0.1 f1), the stepper motor

1. moves the piece some distance (let's assume it is 0.1"),
2. reverses back that same distance,
3. then re-executes steps 1-2 until I stop LinuxCNC.

Hallo und danke,
vor etwa 1h habe ich eine andere Möglichkeit gefunden. In der pncconfig auf der zweiten oder dritten Seite gibt es eine Option, die man an oder abwählen kann. Heisst sinngemäß "Homing vor MDI" notwendig.