Advanced Search

A little underpowered, if you have one give it a go, if not I wouldn't recommend buying one.

T630 isn't a bad choice for connecting to a mesa Ethernet card.

T610 Plus maybe ok for a Parallel Port system with an RTAI kernel, or Debian Wheezy might be the go. 2.7.x Linuxcnc

More findings:

I am running g95 with a manual bldc controlled spindle. The jerk happens at around z -17.2 everytime no matter if the spindle was running at 1200 rpm or stopped or at 100 rpm. It never happens before that or after that no matter how much time was given for the axis to reach at that point. So i can safely rule out any problems with electrical noise and such issues (though my control panel isnt good enough).

Now if i change the backlash from 0.08 to 0.0- the problem vanishes.

Even on the graphical interface it looks like a straight like, g70, g71 trie to do a small move at z-17.2 for reasons unknown, for which the backlash motion is triggered. I am not sure yet. Let me increase the backlash to much higher numbers to see if the jerk increases or stays the same as before.

Thx for the reply.
I know that linuxcnc has 9 axis in total and the name in different.
For now i have the linear guide rails and i'm working in Solidworks to build the 3d model of the entire build.
What i dont know is how to use linuxcnc for the spindle configuration.For example should i use a servomotor for the spindle head, main and subspindle or use a different style like a regular 3 phase motor with a VFD comanded by RS485 and then when i need position i can switch to servomotor or a stepper motor.
The advantage will be with 3 phase motor i can get higher rpm.

Hello I wanted to know if it was possible to install linux cnc on the HP T510?
Here's a link for the thin client specs www.parkytowers.me.uk/thin/hp/t510/

This is just soft-limits as I am using absolute encoders and while I "home" it only sets the axis as homed, there is no travel or switches involved. I may add hard-limit but that is really more of a belts and suspenders solution.

I am not understanding how HOME_OFFSET will fix this for soft-limits. My understanding of HOME_OFFSET my be wrong. but it will offset the home and then the soft-limits will be offset, but I can still jog right to them, and my "little over error" will still be an issue.

Does the LIIMITS OVERRIDES only there for hard limits or will also work for soft-limits?

This all can be just me and my very limited understanding of how to correctly set-up high resolution absolute encores and soft-limits.

I took a slightly different direction.  By adding a "probe-connected"  hw pin, I can select probe or toolsetter.  This also has the benefit of checking if the probe is connected in the probe sub routine.

As my probe uses a USB-C connector, it's not a USB device; it simply uses D- and D+ as the trigger pins.  And the fact that USB-C can be flipped, I was able to use the CC pins (which are tied together on the probe's USB port) to have a hardware pin when the touch probe cable is connected.

BTW: the toolset I have is NC, so I needed to invert the pin. (I guess lcec does not support '-not')

here the sniplet of my hal: 

I am running this off a 7i96s. I never changed the servo period, so it should be default. The P value for both axis is 1000

“hm2/hm2_5125.0: Smart serial card hm2_5i25.0.7176.0.0 remote error = (27) Over Current”

Means there is an an issue (most likely a short) on one of the 7I76 field outputs
 

Particulars on my set up at the end. My machine crashed and I’m way behind on a deadline. Thought I’d throw some questions out there in the hope of getting to the bottom of this quickly. Running 2.9.2 QT Dragon HD.

Everything has been running well (software at least) for the past 6 Mo. Today I was making a cut similar to other work I’ve been doing and the spindle stopped spinning half way through the job.  QT showed the error “hm2/hm2_5125.0: Smart serial card hm2_5i25.0.7176.0.0 remote error = (27) Over Current” I assumed this involved my Modbus connection to my Hitachi VFD and there was a VFD complaint re: the spindle. I power reset everything and restarted, hoping to get lucky. 

After restart and Homing, in QT Dragon MDI I issued an s5000 which should start the spindle, right? Nothing.

I pulled up Halshow for the wj200 driver for the Hitachi VFD. The Modbus watchdog is ticking, the heat sink temp seems to update, and it shows ready and enabled. s5000 does not show the commanded-frequency (Driver setting) to the VFD however.

When I unlink commanded-frequency and attempt to set with halshow, I lose the Modbus watchdog. With s5000 set, the VFD just shows 000 on its display. The fluke in AC mode seems to agree there is nothing going to the spindle. 

So. Everything else on the machine is healthy/ power is good. The VFD seems ok (watchdog, sets ready when machine enabled, HS temp). I’m prepared (sorta) to believe that the spindle died for some random reason, BUT I can’t get past the fact that I don’t seem to be able to command the VFD to turn the spindle on.

Maybe I’m going at this wrong? I’m avoiding trying to command the VFD from its front panel because the process is error prone (for me at least) and I wouldn’t know if the spindle was busted or I just screwed up the VFD commands.

Thanks for any suggestions. I’ll need to start doing things the old fashioned way pretty quick I I don’t get this thing running.

Machine summary: Gantry style router. Clear path servos. Quad core I7 with 5i25/7i76. Hitachi WJ200 VFD. 3hp Chinese WC spindle with ATC. 

I finally finished a little project I had in my mind for a long time. I have some pretty common TOAUTO glass scale DROs with readout which I always wanted to connect to my LinuxCNC machine(s) to get DRO output on my touch screen and maybe also experiment with closed loop operation.

It can be done cheaply, total cost is maybe $30 in parts total, no custom parts. In essence it's based on a RP2040-Zero and a TXS0108E level shifter. The RP2040 acts as a regular USB device which can be accessed from a custom HAL component. This is not using some serial or ethernet connection but it's a full speed USB device implementation which means I can get about 1000 readouts per second. Is it as reliable as ethernet? I would not think so, but for $30 you can't ask for much more and my ethernet ports are limited

The way the electronics work is that you splice into the existing signals on the DB9 connectors on the DRO readout. So you get to keep your existing DRO panel fully working. My current hardware setup for that is rather janky, but modifying the existing DB9 connectors will probably be easier and nicer looking. The most tricky part here is that the cable lengths need to be as short as possible and ideally shielded if you want to avoid noise affecting the signal.

More information, full code and images for this project here:

github.com/tinic/rp2040-encoder

Someone should be able to solder this up in an afternoon after ordering the parts from Amazon the day before...
 

Sounds like maybe a damaged step/dir output.

It could also be marginal drive if you are using differential
wiring to a step motor drive. (its suggested to use
single ended drive with opto-isolated step/dir inputs
and differential drive with servo drives with line receiver inputs)

You can check the STEP/DIR outputs with a voltmeter.

 When the 7I96S is first powered up, the STEP/DIR pins will
be in one state and when LinuxCNC is launched (before starting
any motion), the states will be reversed. With no load, the outputs
should  equal the 5V supply  voltage in one state and near 0V in
the other state.
 

I've been looking into RIO for couple of days, reading forums and one question i can't find the answer for, may be it is obvious for all but me, what is the data protocol used in RIO over the spi? is it the same as Mesa LBP16 commands requiring hostmot2 or something else?

I'm sorry.
It seems it was my misunderstanding.

I've had a problem for a few runs where my X axis has been stalling while traveling to the right, and today it completely stopped working entirely. I've traced the problem all the way back to the mesa board.

By plugging in the X axis control lines in Y or Z's control ports on the board, it functions as expected. That means its not the wiring, the drivers, not the stepper itself, but something on the Mesa itself.

I've not changed anything in the INI besides some homing offsets for quite some time and it functioned perfectly for a around 6 months prior. There has been some temperature increases, but the mesa is in cased with 2 120mm fans facing it.

Has anyone seen or had this problem before? Is there a solution you can suggest?

You would probable need a daughtercard because
the XY100 interface needs 4 differential outputs and
1 differential input (that is you could not directly connect
to P1). Something like a 7I78 could do.

Without buying anything, you could test the galvanometer
with a 7I95T config that steals 2 step/dir channels to get the
XY100's 4 differential outputs and use a sserial input for the
differential input.