Advanced Search

Context: An old Boxford 160 lathe adaptation, using the (fabulous) Mesa 7i76e card (integrated FPGA/2-port/massive break-out of I/O/Steppers etc). Started too many years ago and been through various incarnations, LinuxCNC uplifts etc. Never really used in anger, but more for learning about LinuxCNC, in between juggling work, the wife and various cats. Now that I'm retired I can start to concentrate a little. A long winded way to say I think it used to work but now...

Somewhere along the way something has happened. I have push button controls for jog x+/x- and z+/z-, with the jog speed controlled by an analogue pot, From memory, this all worked. Then retirement hits and I get more time to play. The behaviour now somewhat peculiar. X+/- work as expected. Z+/- are more erratic. Turns out, through HAL-Show/Scope that I have z+ on 7i76e.0.input-08 and z- on 7i76.0.input-09.

If I activate (field voltage to input) input-08, the resulting waveform on halscope shows an erratic 0/1 value for the duration of the field voltage being applied. Once field voltage is removed then the signal on halscope reverts to a steady 0.

If I apply field voltage to input-09, then input-9 is shown high on halscope and input-8 reverts to the erratic 1/0 value whilst the voltage is applied to input-09. Removing voltage from input-09 and both input8/9 on halscope revert to 0.

The observation on halscope describes perfectly the observation on the machine - traverse in the Z axis is erratic to the point of occasional reverses of direction and/or stuttering of the jog.

Particularly as my fuddled brain thinks that when I last played with this this all worked, I'm thinking this is likely to be a hardware issue on the 7i76e card. I've quickly belled-out all other inputs and they appear to work as expected. This does mean I can re-wire to use an otherwise unused input, but this irks me.

Has anyone experienced anything like this before?, and is there a solution (e.g. a different bit-file for the FPGA?)

The nature of this is peculiar to my mind, that this is likely tied not so much to a IP fragment of the FPGA, but more likely individual hardware between the terminals on the board and a FPGA port pin. Particularly as the input-8 looks to be in someway coupled to input-9 I'm inclined to get the associated pins under the microscope and reflow the joints, but that's a job for another day. This post just to understand if anyone has witnessed similar and found a solution?

Regards,

Mike

Normal config should work as is from the wizard.
No need to change PID nor anything else for open loop stepper, there is nothing to choose, except the step/unit and maybe rarely timings.
Even if the drives are "closed loop", there is no difference from normal open loop stepper drives as the loop is closed on the drive, not in LinuxCNC.

Hi,
Can someone please give me some more information about how to use linuxcnc with mesa 7i76e for leadhine stepper controllers. I generated the config with pncconf but there is no way to choose open or closed loop. So the tool generated closed loop i found on github this config.

github.com/medicusdkfz/LotteCNC

so i changed also like he dose back to open loop but is this correct`?

# ---closedloop stepper signals---

#net x-pos-cmd    <= joint.0.motor-pos-cmd
#net x-vel-cmd    <= joint.0.vel-cmd
#net x-output     => hm2_7i76e.0.stepgen.00.velocity-cmd
#net x-pos-fb     <= hm2_7i76e.0.stepgen.00.position-fb
#net x-pos-fb     => joint.0.motor-pos-fb
#net x-enable     <= joint.0.amp-enable-out
#net x-enable     => hm2_7i76e.0.stepgen.00.enable

# ---openloop stepper signals---

net x-pos-cmd    <= joint.0.motor-pos-cmd
net x-pos-cmd    => hm2_7i76e.0.stepgen.00.position-cmd
net x-pos-fb     <= hm2_7i76e.0.stepgen.00.position-fb
net x-pos-fb     => joint.0.motor-pos-fb
net x-enable     <= joint.0.amp-enable-out
net x-enable     => hm2_7i76e.0.stepgen.00.enable

But what about the PID why i need the PID? Do i need to change anything on the PID settings? 
Dose anyone can share a config for a open loop steper for mesa 7i76e

Here i will share my working config and i will commit my progress here if anyone needs this

github.com/mgiaco/ecam_cnc

Thanks alot
mathias
 

7i76eu_7i76x1_pktv3d.bin

 or

7i76eu_7i76x1_pktv2d.bin

For older LinuxCNC distributions

Hello,
Hope you are well,
I have bought a 7i76EU and would like to know if you have any specific firmware I should use.
My setup is Linuxcnc 2.9.7, VFD is Omron MX2 and I will connect this using the RS-485 mode. Other config details, I am using 5 Gecko Stepper Drives driving X1,X2 Y, Z and A rotary axis. I don't have any encoders.
All Jumpers are default and I have a unregulated power supply that I can connect to the board.
Can you also confirm if a CAT5 cable or higher speed cable is required.

Thank you.
Kind Regards,
Orrin

   

Hello All,
I have an error after trying to set up a 7i76E with a Asus Essential 14 N150 NUC.
Running the latest Debian and installed Linux CNC as instructed by Mr Rod on his youtube video.
All the installation went smoothly, but i am facing this error during my connection to the card.This is my second install, I have previously set up a 7i96S system and is succesfully running.
I am running a 12V smps for the 7i76E board, could that could be a problem.I think I might have missed something here.Please find the error report attached.
Thank you,

Antony. 

tommylight wrote:

@RodW,
50 minute video for a 3 minute setup, really?
Here is everything in one place and does not take 50 minutes:
forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

If you had of followed the link It would have taken you to the exact spot about 16 minutes in where I discuss the networking in that 50 minutes. Its a very old video now but still current.

@RodW,
50 minute video for a 3 minute setup, really?
Here is everything in one place and does not take 50 minutes:
forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

Here's the thing, it may be difficult to tell what happened, but the card did not leave Mesa with
a blown  27 Ohm resistor network and a bad 74ACT541. Also, it is important to know what happened
so it does not happen again.

The good news is that the card is repairable. Mesa normally charges $35.00 for minor repairs like this.

adhamamer wrote:

Im pretty confident that i did not cause this damage, all the wiring Ive done on tb2 was also done on tb3 to a standard tb6600 stepper driver
What do you guys think i should do?

I have no idea what do you expect from us to tell you as i am sure you do not want to deal with reality.
My reality is: I have over 80 or 90 of Mesa boards in daily use, never ever had one fail nor had issues, ever, mostly on industrial machines in use 24/7/365.
P.S.
This is my polite answer as you said "im pretty confident...".
Next time try to figure out how that happened instead of insisting it did not happen.
Also, whatever the price of any Mesa board is, i have to pay at least twice that to get theme here, and i pay that gladly.

Update:

MESA Replied:“OK, examined the cardU15 (STEP+/DIR+ 0..3 driver) and RN31 (27 Ohm resistor networkin series with STEPO+/DIRO+ and STEPO-/DIRO- pins) were both damaged.RN31 had opens on the STEPO+ and DIRO+ pins.Damage was likely caused by connection of theSTEPO+,DIRO+ pinsto either something outside the 0 to +5V range (even briefly) ora long time short of the STEPO+,DIRO+ pins to 5V or ground.”

Im pretty confident that i did not cause this damage, all the wiring Ive done on tb2 was also done on tb3 to a standard tb6600 stepper driver
What do you guys think i should do?

Hi,

Setting up Probe Basic 0.6.6 on a 4-axis gantry machine (MPCNC with a fixed rotary B axis mounted at the end of the Y travel).

Configuration:
- LinuxCNC 2.9.8
- Mesa 7I76E (Ethernet)
- trivkins coordinates=XXYYZB, 6 joints
- B axis is a rotary chuck, fixed position at Y=700mm

What works:
DRO displays all 4 axes correctly using DRO_DISPLAY = XYZAB (A axis is unused but present — there is no XYZB option available).

What does not work:
The backplot renders the toolpath as 3-axis only — B axis rotation is not applied when building the path. For wrapped rotary applications (tube machining) the toolpath preview is not meaningful.

Also, machine bounds are not displayed in the 4-axis config, while they display correctly in the 3-axis config on the same machine.

Are there any plans to support wrapped rotary backplot rendering in Probe Basic / qtpyvcp?

3 axis configuration - mpcnc_probebasic.ini
4 axis configuration - probebasic_4b.ini

Hallo Zusammen ! Da bin ich mal wieder mit einem oder besser mehreren Problemen... Mittlerweile weiß ich nicht mehr weiter. Meine Fräse spinnt ja des öfteren,da habe ich mich schon daran gewöhnt,einfach am nächsten Tag wieder Versuchen ,dann ging es meistens wieder. Fehlermeldungen wie" Radius to end of arc differs from Radius to start und ähnliches bin ich ja schon gewöhnt. Da half oft einfach einen anderen G Code zu Laden,Starten und gleich wieder Stoppen,dann den Ursprünglichen Code wieder Laden und dann ging es . Jetzt Kommt aber die Fehlermeldung,dass die Fehlermeldung" Bewegung Linear in Zeile 19 würde Anschlag der Achse 1 Überschreiten! Das Dumme ist nur,dass das Werkstück 40mm Durchmesser hat und ich nach jeder Seite 250mm Weg über habe. Jeden Start quittiert die Maschine mit einem sofortigen Stopp. Ich habe für das Werkstück 2 G Codes,einmal für eine 3,17mm Fräser und einmal für einen 2mm Fräser zum Schlichten. Der G Code für den 3,17mm Fräser läuft ohne Probleme,der für den 2mm Fräser nicht. Ich habe schon ein neues Setup Probiert,für jeden Arbeitsschritt einen eigen G-Code erstellt,alles ohne Erfolg. Meine Steuerung ist eine Mesa 7i76e ,an allen Achsen Closed Loop.  Das Nonplusultra wäre jemand im Raum Laa an der Thaya in Niederösterreich,der sich das mal in Natura gegen Bezahlung natürlich anschauen könnte. Ich bin mit meinem Latein Mittlerweile am Ende. Ein neues Bedienpult neuem Steuerrechner(I 5) steht auch schon in den Startlöchern,da bin ich auch noch am Tüfteln wegen Werkzeuglängen vermessung und Antastfunktion ect. G-Code häng ich mal an,vielleicht findet wer den Fehler,ich werde nicht daraus Schlau. Mit Dank im Voraus !

Unless you changed the firmware, I doubt that that's the issue.
 (all cards are tested and shipped with standard firmware)

You think it's worth it to give it another shot with flashing another firmware before returning it or do you advice against that?