Advanced Search

If i remember correctly, 7i85S has 4 stepgens and 4 encoders and a smart serial, and Argon drive does work with step/dir signals, so that is all taken care of.
7i75 should be a break out board with isolation (again if i remember correctly), so it can be used for other signaling.
This might need a firmware flash, although any existing firmware that has 7i85S in the name will work, so do try the included firmwares on the downloads page of mesanet.com
With Mesa any functional pins like step/dir, PWM, encoder counter, etc can be used as normal input or output pins if those functions are not required in hal.

I made a simple test. Removing all wires from Mesa to VFD and making a short on AVI <=> +10V as well FWD <=> +12V. If I'm right the spindle should start right after I power the setup. But the spindle didn't start. Is my understanding correct that the VFD is broken?

What is the required part tolerance?
If it can be 0.1mm then
G64 P0.1
Should be much faster
Or if doing decorative stuff, even G64 P0.3 or more should be OK, and much faster to run/finish.
0.01mm is very high tolerance, even metal fitting parts can deal with a bit more tolerance.

Dear gods, I've got the cards mentioned in the subject, and my purpose is to run a lathe with:
- STEP/DIR steppers for x and z axes
- quadrature linear encoders for x and z axes
- Argon servo drive to run the dc spindle motor
- a stepper, a solenoid and an absolute encoder for a tool carousel (although this one might be easier to control with a separate microcontroller?)
- relays for coolant and lubrication pumps

I've found that PncConf does not have the firmware option for my selection of cards, and now I have little clue as to how to proceed.
Why I'm in such a pickle is that I had a friend pick those boards for me, but later, he has become too busy to help me with setting them up.

So, I suppose my question is what should I do? Money or sunken costs are really not an issue. If I should buy new cards that are easier to setup, or pay someone to guide me, then I will.
Oh, and I do also have a 7i73, but no panel or pendant built or even planned yet, so I'm not so worried about that one. For now, I will be a happy man if I can just get the machine to run at all.

Huh weird.

Someone more knowledgeable will probably step in. The only thing I can think of is the acceleration set the same for all the axis in motion?
E g. If x is 1000 and y is 500 g64 might limit things to 500 even if moving x only to make the math easier.

With no g64 linuxcnc rounds corners substantially to maintain speed. So it makes sense it would take longer with g64.

Try with a bigger g64 and see what happens. Often you can use a big g64 for roughing and a small one for the finish pass if machining. However if you are running a plasma/laser/3d printer etc obviously you can't do that

I hope my processing path and programming path are accurately controlled within a certain range, so I use G64 P0.01 to control.
But after using G64 in the G code, my acceleration became slower.
It is not just that the acceleration at the inflection point becomes slower (for example, I draw L).
it will take a longer time at the line acceleration of the X/Y line (from 0 to MAX_VEL or from MAX_VEL to 0).
Only one axis participation movement will be longer.
why is that? Can I let it run according to the maximum acceleration I designed?

Like I said get X installed, try to run a desktop session and see how that pans out. 180us latency doesn't sound promising. There's no point trying anything with Linuxcnc if a basic X session is like swimming through molasses.

Hi,

Now finally we regrouped the fillets with the recorded tooldir path.
Now each gcode line has it's own tooldir curve. So now interpolation for the tooldir curve is easyer to do from 0-1.

Now i must make a algo to interpolate over the tooldir curve. This tooldir curve is a set of waypoints.
First calculate total lenght, then try to interpolate over the lenght to get ta point.

Well snap, jealous of those which .279 works. Doesn't seem to like my lenovo & 4ax milling machine for some reason
Reverting back to 5.4.258 sorts it in my case. 

Observations:
1. Upgrade from .258 -> .279 went smooth. RTAI starts and everything. (That's all good).
2. The isocpu grub init is indeed mandatory. Does not start otherwise. (I personally don't care!)
3. On a PC cold boot I can; start linuxcnc, home the machine, jog. (That's all good).
4. I do however get a new RTAPI ERROR. I didn't had this with 5.4.258. (see visual). 
5. If I close linuxcnc, it's impossible to start it up again. Needs a full machine reboot. (see attached logs/traces). 



 

Use the 'Show HAL Configuration' to verify that

'hm2_7i76e.0.7i76.0.0.spinena' is TRUE
and
'hm2_7i76e.0.7i76.0.0.spinout' is set

If that is ok then check if you actually have a voltage arriving at VFD 'AVI'.
Also check the VFD parameter settings to allow the spindle speed to be set by analog voltage input 'AVI'
If you have a potentiometer handy then you can connect that to the VFD analog input and see if you can change the spindle speed by manipulating the VFD inputs manually.

I made the change you advised, but no success.

@Hi Arciera,

Yes the deviation is within 5mm. It's less then 5mm.
The blend value is used as trim value seen from intersection point of curves.
Each curve has a trim value on both ends.

Now i have a little video, that shows also the tooldir symetric axis are updated in blue.


Now also a hard part comes. For each gcode line i need a correspondenting gcode tooldir path.
So i have to split the b-splines at the blue tooldir lines. Then i need to regroup a few curves together.

Hi Alex,
I am using: Debian Bookworm, kernel 6.1.0-22-rt-amd64.
The display is 1366x768
Your suggestion does not solve issue.
Any update new solution ?
Thank you.

Try connecting the mesa 'En-' to VFD 'FWD' and see if you can get the spindle to run in forward direction.

[edit]
Also, you need to uncomment this line in your hal:#net spindle-enable <= spindle.0.on

I'm a student working on the CR3-535M controller, which is used to control the RV-12SL 6-axis robot arm from Mitsubishi. I'm encountering the error code H109n* (H1091,H1092,H1093,H1094,H1095,H1096). The troubleshoot detail explanation and the rotary switches of both servo amplifiers shown below. I've tried changing the rotary switch positions to 0 1 5 2 3 4 for J1,J2,J6,J3,J4,J5 respectively but that still didn't work. So i come here to ask for your help ! I'll provide any information required. Thanks.