Advanced Search

This is particular is quite weird:

hm2_7i90: selected address 0x8100

Not really sure whats going on

Does the port at 0x378 work as a normal parallel port?
 

I've seen a couple of "solutions" to this, but my question here is: what's the canonical way to detect that linuxcnc is shutting down and/or exiting, or isn't running, using the python linuxcnc.stat.poll() api ?  I can start my python script in hal using loadusr, but there's no unloadusr, and I can't just run it at computer boot because linuxcnc.stat() just fails if linuxcnc isn't running yet.  I tried using the parent PID but that isn't reliable (and prevents you from manually running the script in the background)
I've attached my script.  I'd like to cleanly detect that linuxcnc has exited or the computer is shutting down, and send a final MQTT message to home assistant to update the status to "off".
 

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.9
Machine configuration directory is '/home/cnc/linuxcnc/configs/Cnc_xyz'
Machine configuration file is 'Cnc_xyz.ini'
INIFILE=/home/cnc/linuxcnc/configs/Cnc_xyz/Cnc_xyz.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=qtvcp qtdragon
COORDINATES=XYZ
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./Cnc_xyz.hal
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
hm2: loading Mesa HostMot2 driver version 0.15
hm2_7i90: loading HostMot2 Mesa 7i90 driver version 0.3
hm2_7i90: wrote control 0x04
hm2_7i90: read status 0xFE
hm2_7i90: selected address 0x00
hm2_7i90: read data 0xFF
hm2: no firmware specified in config modparam!  the board had better have firmware configured already, or this won't work
hm2/hm2_7i90.0: Low Level init 0.15
hm2_7i90: selected address 0x8100
hm2_7i90: read data 0xFFFFFFFF
hm2_7i90: read status 0xFE
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
hm2/hm2_7i90.0: invalid cookie, got 0xFFFFFFFF, expected 0x55AACAFE
hm2/hm2_7i90.0: FPGA failed to initialize, or unexpected firmware?
hm2_7i90.0: board at (ioaddr=0x0378, ioaddr_hi=0x0778, epp_wide ON) not found!
hm2_7i90: rtapi_app_main: Invalid argument (-22)
./Cnc_xyz.hal:9: waitpid failed /usr/bin/rtapi_app hm2_7i90
./Cnc_xyz.hal:9: /usr/bin/rtapi_app exited without becoming ready
./Cnc_xyz.hal:9: insmod for hm2_7i90 failed, returned -1
1645
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

these are the files and the response

Item sold

rodw wrote:

A quick Google said:
Burgmaster turret drills are well-regarded for automating multi-step machining. They house a cluster of spindles that automatically index and rotate to the next operation—such as drilling, countersinking, or tapping—without requiring manual tool changes.

So my question is, is the turret under CNC Control? was this broken with the Mach3 conversion? Can the function be restored? That's the LinuxCNC opportunity.
Seems to be designed for drilling and tapping so caveats around milling would be similar to that for drill presses.


 

Yep the turret works mechanically by going up on the z axis to the very top so it activates and rotates one position, it has a bit of play on the tool bearings, I didn’t measure the play but it is really small but it depends on the tool station some have more some less, maybe changing the bearings.
I thought about taking out the turret head and replace it with a Chinese head and mount the turret on a manual drill press.
Or ditch the idea and start looking to other machines because milling is the main reason I want to buy a machine.


 

Thanks for the answer
Everything is expensive here, old beat up fadals goes for more than 22k an old bridgeport romi d 1250 without numeric controller and unknown state of drivers and servos goes for 13.5k but can’t afford them
I have worked on machines before fixing some retrofitting others but I have never had my own so I kind of know the market here.
Money is really tough here I saved for a long time so I don’t know if it will be worth it, at least is a working machine

Can you post your hal/ini files?

The IO addresses (ioaddr and ioaddr_hi) are crazy

hi, i have this error.

Every shape has a variable named cuttingdepth and if one makes cuttingdepth be negative the endmill goes up instead of down so we'll have to replace the endmill with an extruder if we need to make "precise pieplates".  we'll also need to add a bunch of g-code to run the extruder, (and the heaters/fans?)  .  A g-code driver for that should be available from somewhere, Prusa used to be open source, but could be quite large for implementation here, but its something to think about.

rodw wrote:

I'd love to see a solution where all the maths was applied to a bend list. eg, define  tool,  knife,  material for that list, then it would be a simple matter of setting the desired angle and backstop position for a list of bends. The maths is well known and every CAM program I used knew it.
 

Agree!
I see the potential for an open source LinuxCNC press brake controller.

Try it out.

There's also an increased toolpath history.

It also refreshes every 50ms, because 100ms doesn't create pretty circles, but it also puts more strain on the CPU.
For simulations without a rotary axis, 100ms is fine.

Is it possible to have the entire scene refresh at a standard 100ms, and the toolpath itself at 50ms?

There are so many things that force a system upgrade, Components fail, new drivers needed and so on.
Without upgrades you would miss out on so many amazing improvements to LinuxCNC. QTplasmac and QTdragon are cases in point and running master branch with them is almost mandatory. What about 9 axis look ahead or S-curve jerk limited trajectory planning?

You just need a plan and a fall back position, I generally create a new config in Mesaconf or stepconf with very rough settings. Then once motion is confirmed, cut and paste all of my original ini and hal settings accross. That gets me running. Then its just a matter of adding all the new nice to have features. 3D probing, spindle torque display and so on. It only takes an hour or so.

Sorry but I like to stay pretty current. It makes support much easier. 
Did I tell you I get a bit annoyed when people say I have this working machine on 2.5 and it broke when I upgraded to 2.9? The truth of the matter, it broke several times all at once. Have you any idea how old 2.5 is? I've been using LinuxCNC for over 10 years. 2.7 was where I started but 2.8 came out before I finished my first config, so I upgraded straight away because It had features I wanted. I'd venture to say you will have less downtime if you stay current as you only make small steps at a time. upgrading 4 versions? you might as well adopt Mach 3!

EW_CNC wrote:

Yes, It is possible. I am regularly using the press brake that I retrofitted in this thread.

forum.linuxcnc.org/30-cnc-machines/42100...ons?start=100#228476

The homing still has issues, but the ram functions good. I use the backstop only on occasion if I am bending a high quantity of parts. I just calculate the offset from the backstop's start position without homing it. I believe it could be fine tuned to work better, but for the low volume of parts that I bend at a time, it does the job.

I don't have a press brake anymore, but the one I had was retrofitted with a commercial CNC bending controller. It was so awesome!
I'd love to see a solution where all the maths was applied to a bend list. eg, define  tool,  knife,  material for that list, then it would be a simple matter of setting the desired angle and backstop position for a list of bends. The maths is well known and every CAM program I used knew it.

Realteks became a problem with Bullseye (5.10 kernel) but we never released a version on it so the first issues were found with Bookworm (6.x kernel) when the kernel NIC driver architecture changed.

I think the minimum spec is i5 (4 core ) with Intel NIC.

People became a bit blase with PC specs until the recent kernels as above, but when I started with Mesa you had to compile the kernel to get the required  PREEMPT_RT we took a lot more care with PC selection...

Yeah, Realtek had/has issues with 6.x.x kernels, a lot, but worked fine with older kernels.
Probably due to power saving options being implemented everywhere...