Advanced Search

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.
 

Hello! New to LinuxCNC and Mesa and trying to set up a 6-axis (+2 galvo axes) laser system. All 6 of the step/dir and encoder pins of the 7i95T are anticipated to be used, and trying to figure out how other pins can be repurposed.

Is there a firmware version for the 7i95T with xy2-100 support (xy2mod)? The unit currently has the default 7i95t_d.bin firmware loaded.

Which pins on the 7i95T could be used for controlling a 2-axis galvanometer? Would the Serial 0 and Serial 1 pins be suitable?

The manual mentions that the P1 expansion port can be used to expand I/O including for more step/direction channels. Can these pins be redefined for such purposes directly or is an expansion card / daughterboard needed?

Can (which?) pins on the 7i95T be used to control an IPG laser (please see attached image of pinouts from laser specifications) or is another card needed? 

hello gentelmen,

I did some stuff... if you are familiar with TC3 and you have working configuration.. You cas use the consoleTool which translate complete .xml configuration from Beckhoff ethercat master to lcnc ethercat master by drag and drop your right working config .xml + initCmds should be imported too

regards

Yes.
Yes.
Yes.
...
But first you have to stop thinking DMG or Dosan have good controllers, most industrial controllers suck badly for some work while being very good for some other work.
Point being, C1, C2, C3 are very wrong names for rotary joints/axis, LinuxCNC use A, B, C and they are tied physically to X, Y, Z, in that order so very easy to remember and use.
As for the rest, the above Yes's are for everything else you asked, LinuxCNC can do 5 Axis (can do 9 axis XYZABCUVW and each of those can have more than one joint/motor/drive controlled separately), yes you can use a parallel port or two or three if you need more inputs/outputs, parallel ports can be set to IN/OUT/X mode, etc etc etc .... the list is very, very long.
And most importantly, YES, start building the machine, no matter what i or others say, just build it!

Edit:
Just read it again, C are spindles in axis mode so forget the part of me complaining about it.

No, homing to index is common and fully supported.

I'm just saying that the actual index hal pin is not useful
for homing. The index-enable pin is what's used to communicate
index information from the hardware/driver to LinuxCNC

That is, this hal statement:

net phaseZ [HMOT](CARD0).encoder.00.input-index

Doesn't do anything useful.

But this hal statement:

net b-index-enable joint.3.index-enable <=> [HMOT](CARD0).encoder.00.index-enable

Allows LinuxCNC to enable index detection AND allows the driver to inform LinuxCNC
when the index has been detected.

To test whether the index hardware is working (assuming you can move the axis past
an index mark), you would:

With LinuxCNC running,  use halshow to watch the signal b-index-enable
and then with either halshow or halcmd, set b-index-enable true"

halcmd sets b-index-enable true

halshow should now show b-index-enable true

now, if you move the axis past an index mark, b-index-enable should go false.

This is how you test for correct index operation.