Advanced Search

I would use 7i96sd_mpgp1.bin firmware as that was designed for this use.
You can use a software MPG encoder but since the inputs are sampled
at the (relatively slow) servo thread rate it will not work very well.

Take a look at this thread:

forum.linuxcnc.org/39-pncconf/51733-7i96...-configurator#295487



 

My problem just got worse. Now the error has returned even while using "sudo ethtool -C enp0s25 rx-usecs 0". Its just like before popping up every 5-10 minutes and stopping my cut in the middle of the process forcing me to recover the cuts and it is very difficult. Any ideas of what can be causing this error? and also can you guys maybe recommend working pc models so I could maybe swap the computer for one that works how it is supposed to.

Hi everyone,

This is my first post in this forum, so first of all i want to say that i am really impressed by this community. You have been a great help in my cnc building journey. So Thanks you 

I upgraded my controller setup from an old PC with parallel port interface to a Mesa 7i96s card connected to a newer PC. Now i am working on my pendant/mpg and have modified it to be directly plugged into the P1 expansion port. 

Since i am new to the mesa hardware i want to make sure that my setup does not have a fatal flaw. I basically have two questions

1- my pendant has 6 push buttons and two rotary switches (for axis and jog speed selection). Each button is wired this way, for example Pin 3 and Button 3:

Pin3 (P1) -> button 3 -> ground. 

So the pin gets pulled to ground when the button is pushed (active low). I read it should be done this way since the P1 pins have pullup resistors and are always high when the board is powered up. Is this wiring ok? Do i need extra resistors to limit the current? Many buttons can be pushed at the same time.

2- concerning the mpg/rotary encoder. i have read several posts talking about custom bit files to add encoder "functions" to some pins. Is this step really needed? My former setup had the a and b channels of the encoder connected to normal pins, the signal management was done in the hal. I want to avoid flashing new bitfiles if possible at this stage because i am still not very comportable with this new (to me) hardware.

Thanks !!

Yes, the maximum steprate for Mesa FPGA cards is only dependent
on the hardware. It is independent of the host controller.

This is because the steprate is set by a digital oscillator.

The host does determine the update rate of the steprate,
so even though you could have a 10 MHz steprate at a 1 Hz
update rate it would not work at any reasonable acceleration rate.
 

At first glance:

Change  step times from 500 to 4000

The charge pump needs to be done with stepgen 4
(the software charge pump will not work)

Recent versions of pncconf know how to setup a stepgen as a charge pump
 

I'm not aware of an XML import.
It is possible to use an external database for tool management:
linuxcnc.org/docs/devel/html/tooldatabase/tooldatabase.html

As an alternative it might be possible to convert the xml tool data to ordinary list data used in linuxcnc (eg by a custom python script):
linuxcnc.org/docs/devel/html/gcode/tool-....html#sec:tool-table

Homing defines your absolute zero position (ie G53), whenever you actually cut a part you will be using a work coordinate system (ie G54 ... G59) that is set to a corner of your machine vise or the part to be machined.

Okay, thats why they were opposite, homing vs traveling direction, as I believe, I guess I'm missing some very basic concepts here.

I`m trying to understand how my machine should be set for home.
The travels are X 1000 mm, Y 450 mm and Z 400 mm.

How should I set the homing to be as trivial and safe as possible?
I thought as my first post:
I'm setting my home positions and to order to:
1st: Z all the way down, nearest to the floor at value 0.0
2nd: X all the way to the left, nearest the lathe at value 0.0
3rd: Y all the way back, nearest to the wall at value 0.0

Should I set 0 values for all axes? This would make my machine runs on negative coordinates all the time, right? What would be typical for a machine like this?

I really appreciate your help, guys.

I can take a look at this next week, now that there's a way to re-create the issue.

 

Depends on how you look at it, i did read Aciera's post and went back to read mine as i though i messed up, but it is OK, i am talking about homing direction, he is talking about motion direction.
I'll try to explain, hopefully i do not make a bigger mess:
Look at it as the table is not moving but the head is moving, then translate that to table motion.
Does this make things easier or worse? I would like to know, thank you.

Hi

I'm just trying to clean up the ini file reads for the Manualmatic wrt setting default values & min/max velocities for jogging, overrides & spindle(s) etc.

As an example, since 2.9 some of the spindle options have now moved to asection so variousoptions have been deprecated.

However, there seems to be some ambiguity between the options that relate to hardware (eg min/max velocities) and those that are solely related to display (eg increment or default velocity). There are also at least some  options (egthat have been deprecated with a reference to thesection but the 'new' options do not appear in that section.

Just to add a little more zest, the generated ini files currently create options that do not match the ini file documentation

Is there a roadmap or similar document that can help me understand what options I need to prioritise and should I raise an issue for the missing deprecated options?

 

want to use HSM Advisor to manage my tools it has a xml export, is there a linuxcnc converter or xml plugin ?

Only the stepgen 00 shows this issue, at least from what I have seen:
 

Is there something I can do to further help debugging/troubleshooting? I am no programming god, but I can get my way around some c code if it's of any use. I'm currently on the "stock" iso 2.9.2, if that makes any difference.

I think I have see that before and it looks like a bug in the mesa_modbus driver.
(the 1 Hz is the modbus timeout/retry period) In my testing, it went away mysteriously
and I was not able to re-create it. Looks like maybe request/reply mismatch in some
circumstances.Can you retry the test with the stepgen position not at 0?
(that would provide a bit more information.)

There are a number of already known bugs in mesa_modbus:

 

Here are the hal and ini files. Thanks for the reply!