Advanced Search

Wrong firmware, 7i76eu_7i76x1_7i88_7i89d.bin is for a 7I76EU +7I88 (P1) + 7I89 (P2)

I'll take a look at making a config for a 7I76 (P1) and 7I89 (P2), but probably tommorow...
 

As you're asking for an interface board I'm Gunna assume you have a 7c81 at hand.
The expensive route but most complete, reliable and expandle route would be a 7i76, not the ethernet version but a plain version that you connect via a ribbon cable. This will give you everything you need except the stepper drivers on board.
In all honesty as a preference I much prefer the "standard" type stepper drivers rather than the types used on the smaller desktop CNC toys and such.
Unfortunately as you've found out there's not a lot of breakout boards available that handle 24v signals, most will be a DIY thing.

That may be, but I have 7I76U and its manual says (www.mesanet.com/pdf/parallel/7i76uman.pdf page 5) that sserial should be on DB25 pins 7-10 (two of them in fact), while 7i76eu_7i76x1_7i88_7i89d.pin file has just one sserial on pins 11-13 and no spindle encoder. It instead has 2 additional stepgens which my 7I76U doesn't have.

Might want to wait for confirmation from PCW, but to me it seems all good, and yes sserial's must be there as 7i76 has a sserial port and uses another sserial channel for IO.

Here it is. 
As I see it, pinout for P1 connector (where 7I76U is connected) is wrong for pins 7-13 (Sserial and spindle encoder)
 

koch777 wrote:

That one has all the right pinouts, but seem to be for older generation of 7I76 (Spartan FPGA?), not sure it will work for my 7I76EU (Efinix FPGA)

It does not work and might brick the card, well i am sure it will brick it, but being Mesa there might be ways to save it, so do not flash that.
Post the result of mesaflash readhmid here se we can have a look.

Hello everyone,

So, I have this configuration:

• Main board is Mesa 7I76EU
• 7I76U connected to main board expansion header P1
• 7I89 connected to main board expansion header P2

Main board's +5V is connected to P5; +24V field power - to TB1.
Actually, never mind, main 7I76EU is not a problem, it works, everything's detected, steppers are moving, spindle/spindle encoder are working, MPG is working.

Now, expansion 7I76U (on P1 header) is indicating communication failure (red led in the middle of te board). It doesn't show up in halconfig (should it?). Field power is there, cable power from main board is there.

For 7I89 I see all 8 encoders, but encoder inputs do not react to signals from encoders. None of the encoder input-a/input-b/rawcounts change despite the fact that physical signals from encoders are. Encoders are TTL and so 7I89 is jumpered accordingly.
+5V power to 7I89 is connected to its P1 and cable power from 7I76EU is activated as well (per 7I89 manual). Encoders are powered and working just fine (checked with oscilloscope).

Firmware I load is from mesa website: 7i76eu_7i76x1_7i88_7i89d.bin
It is somewhat strange as its 7i76eu_7i76x1_7i88_7i89d.pin file has stepgens 10/11 where 7I76U (P1) should have Sserial and it also has Sserial where should be MuxedQCount (spindle encoder). Basically I/O for DB25 pins 7-13 is all wrong for 7I76U.
Probably that's why my 7I76 doesn't work.

I'm afraid to load firmware from post www.forum.linuxcnc.org/27-driver-boards/...7i89-firmware#240149
That one has all the right pinouts, but seem to be for older generation of 7I76 (Spartan FPGA?), not sure it will work for my 7I76EU (Efinix FPGA)
It also has clock high frequency set at 200MHz, while 7i76eu_7i76x1_7i88_7i89d.pin shows 160MHz.

How can I get out of this predicaments?
Can anybody help?

pgf wrote:

Can anyone point to the product I'm looking for?  Or tell me (nicely what I should be looking for instead?
 

That is a very nice way of asking, thank you.
Take a picture of the insides of the electric/control box and upload it here, we need to know what is there to be able to tell you what next.
In general, get the so called "TB6600" drives that use the TB67S109 chip (cheaper and smaller box), they are very good and usually under 10$ a piece, then get an old PC with parallel port, preferably Dell OptiPlex 980 in the big tower case as it has a built in parallel port, and a DB25 to DC25 or Centronics cable, cut one side, strip down some 15CM, use multimeter to find the pins 2, 3, 4, 5, 6, and wire those to the drives. Add a power supply for the drives, be it from old PC or even better laptop adapter or just cram the drives inside the PC case (plenty of room there) and use it's power supply 12V rail. That is it, for under 100$ you have a very reliable CNC machine controller.
Be warned that it will be limited in speed, though, depending on drive voltage and microstepping set on the drives, but it will work for years without issues.
You can add a Mesa to that setup whenever you want...

alright now, any questions?

aDm1N wrote:

I started from scratch with the standard examples. I made some adjustments, and now Remora Input 4 is responding. However, this only happens when the emergency shutdown is disabled in the GUI. So, Remora probably only starts working after that.

that makes sense.
refer to tuxcnc example

I havent tested it, but this looks like what you need to do. you need to modify the portion of your halfile that already references it

DarkPhoinix wrote:

I have recreated the problem with the function generator. Now I am sure the problem lies in the configuration, or so I believe. For now, I would like to know which parameters I need to set to have the same parameters for frequency and pulse times in the hal and ini files (like pulse 1,000,000ns frequency 988Hz). Thank you again for your patience!

refer to the previous posts. replace the stepgen in your config.txt with the DMA stepgen. Make sure the step and direction pins are the NVEM one. The step time and space parts are what you need to configure. I dont know the units. start at 1 and 1 and go up from there.

I need hardware suggestions.  There seems to be a gap in my knowledge, and in my research.

I just got a new CNC router, and it came with a Grbl-based controller.  I always used LinuxCNC in the past on my DIY machine, and I can already tell that I'll probably be happier if I switch to LinuxCNC on the new one.

The most recent incarnation of the old machine was driven by a Raspberry Pi and a Mesa ethernet card.  The Mesa was connected almost directly to the limit and estop switches, and the step/dir lines went to a quad stepper driver board I got from Sparkfun a long long time ago.  The wiring was a horrible rat's nest of jumpers running between pin connectors glued upside down to a plank.  (I'm not exaggerating.) And I don't want to use the Sparkfun board again, for various reasons.

At some point I'm going to want to use the Mesa card with the new machine.  But what I'm picturing, that I don't have, is the "interface" board.  It needs to take 24V power, and have 3 or 4 of those little 16 bit stepper driver modules.  And it needs to have a bunch of screw terminal strips, set up to logically simplify the 6 or 7 pairs going to switches, the 3 or 4 connections to the motors, and all of the interconnect to the Mesa.  Basically what I want is an XYZ CNC router breakout board, with drivers.

But all I can find is complete controllers:  all of what I described, hardwired to an ATMega328, or ESP32.  Or, all of what I described, in the form of an Arduino hat.  Better, but still not very Mesa-friendly.

Can anyone point to the product I'm looking for?  Or tell me (nicely what I should be looking for instead?
 

 

 

Estop is the same way. With Estop, we are connecting a remora.input to LinuxCNC estop. Estop is a very subjective thing, and varies between setups. They can be complicated and require more hardware. Murphy has posted a simple example, and tux from a few pages back has posted a more detailed one.

Notice how the inputs are different on each of their different estops, which makes no difference because we are connecting remora.input.whatever to linuxcnc estop.

Tuxcnc is more complicated, He is using LinuxCNC components (not remora) to configure the estop logic. it includes a latching component, I assume he has one of those red buttons. Im not as knowledgeable with all the estop logic, as I live dangerously. The estop loop is a function of LinuxCNC and you need to connect it to remora in a way that suits your setup.

Sorry about that, I'll take a look tomorrow.

We have 3 phase power in houses, always, rated at 3x380V +-10% and can pull 16A at home from any plug, 32A in workshops/garages.
Lately the local provider started complaining if we pull over 15KW over long duration's, i do not blame them, we have 100A at our disposal.
To spite Americans (since i still refuse to go there despite being granted a Green Card 17 years ago), we can charge a Tesla at home with 22KW on any socket around the house, 60KW if we push it!
And that is with no permissions or requests or installing superchargers!

grijalvap wrote:

I understend what you mean but I want to keep the temporary tools because they are in the GCODE file, the operator don't has to select.
 

If you set the cut parameters up correctly (eg replicating sheetcam toolsets in qtplasmac by importing the Sheetcam tools), the user still won't need to select anything. Instead, Sheetcam will pass the tool number to QTplasmac in the gcode and it will retrieve the corrrect settings. Keep sheetcam the master of toolsets and update QTplasmac if you change settings.