Advanced Search

If you accidentally flashed a Mesa 7I92 with 7I98 firmware you are somewhat up the well known creek.
 The reason is that the Ethernet <--> FPGA connections are different between the 7I92 and 7I98 so you will lose
communications.

There are at least  two possible ways to recover:

1. JTAG (needs a JTAG programmer and Xilinx or generic JTAG software)

2. Trick the card into loading the fallback configuration
You do this by briefly corrupting the configuration data stream just at power up,
Typically by say shorting the DO pin of the flash EEPROM to ground
just at power up (causing a CRC error and loading of the fallback configuration).
If this succeeds, the fallback configuration will blink the init LED so you can tell
that you have loaded the fallback configuration. Once the fallback configuration
has been loaded, you can use mesaflash to re-write a valid user configuration.

 

Is it 7i92 or 7i92T ?
They are not the same, different FPGA.

Then it's a 7i98, so change 7i92 to 7i98 in mesaflash. Or use instead --device ethernet

I accidentally flashed the 7I98 BIT file onto a 7I92 board. Now the 7I92 can no longer communicate with the host. How can I recover it?

This is always the issue when you know nothing and you use AI
Thank you i will try to start again from your repo and adapt the SPI. However, I also tried somehardware modification on the board, not sure it still works correctly.

 

I connected up the hardware in the same way as your system. It didn't want to go to PREOP.
It seems you have been editing a lot, at least some, in lib/soes and I would say that's a big no-no. Leave that as is.
I restored lib/soes from E7000, fixed settings for SPI, removed all SPI from main.cpp, modified loop() and the card is now up and running in PREOP.
 
You shouldn't need to make a lot of editing in lib/soes, only to get SPI running and I think it was fine the way you did it.
All editing for SDOs PDOs etc are done through the EEPROM_generator, no manual editing is needed.



 

Pretty sweet.


Nah that's really sweet. Wot it do ?

That would really require delving into the data sheets regarding the gpios, and how and if the Linuxcnc kernel exposed them, they might be available via sysfs. I have doubts about whether they would be realtime capable.
May libgpiod, but not at all sure.

I think someone may have raised suspicions many many months ago. But my memory isn't what is used........oh ok there's a monkey

Guys
I got the cable! just found one from when i got the 7i78 previously and never used it.

Thanks a lot for the availability to ship one out

How about the bit file, where can i find it? do i need any special firmware editing or something?

thanks

langdons wrote:

tommylight wrote:

Use this ISO
www.linuxcnc.org/iso/linuxcnc-2.7.14-wheezy.iso
Boot the PC from it and run the tests in Live mode, meaning do not install, see if it hangs.

Literally what I said in my post before it "mysteriously" disappeared into thin air.

(no offense to you)

Sigh...

1. You literally repeated my already existing post
2. You linked the wrong ISO location for the same ISO
That can and will absolutely raise suspicion.

This is the only thing that works smoothly for me.
# --- FEED SPEED RAPID POTENTIOMETER'S ---
#BIT direct value
setp halui.spindle.0.override.direct-value 1
setp halui.rapid-override.direct-value 1
setp halui.feed-override.direct-value 1
# SCALE
setp halui.spindle.0.override.scale 0.01
setp halui.rapid-override.scale 0.01
setp halui.feed-override.scale 0.01
# scalemax
setp hm2_7i96s.0.7i77.0.0.analogin1-scalemax 100 # spindle
setp hm2_7i96s.0.7i77.0.0.analogin2-scalemax 100 # rapid
setp hm2_7i96s.0.7i77.0.0.analogin0-scalemax 200 # feed
loadrt conv_float_s32 count=2
addf conv-float-s32.0 servo-thread
addf conv-float-s32.1 servo-thread
addf conv-float-s32.2 servo-thread
net analogin1 conv-float-s32.0.in <= hm2_7i96s.0.7i77.0.0.analogin1
net analogin2 conv-float-s32.1.in <= hm2_7i96s.0.7i77.0.0.analogin2
net analogin0 conv-float-s32.2.in <= hm2_7i96s.0.7i77.0.0.analogin0
net analogout0 conv-float-s32.0.out => halui.spindle.0.override.counts
net analogout1 conv-float-s32.1.out => halui.rapid-override.counts
net analogout2 conv-float-s32.2.out => halui.feed-override.counts

Haha no problem! Yes, I know I still have a lot to learn but I think I'm getting there in my own time. 
I won't bother with pics of floors, roofs or pipes but here's some metal I did earlier in 2019. I look forward to hearing where I'm going wrong!
Like a lot of people on here, I also have a day job - in my case power electronics product development that requires a fair bit of travel to Korea and Japan, in addition to time in the office each week away from home.

Valuable advice NWE, I will keep this in mind going forward.

I can confirm that the home function works. I made a connector from an old VGA cable and tested it on one axis.
Pin 13 <- 0V
Pin 8 <- Home switch (DI3)
Reference run method: 6
I am now waiting for the cables I ordered, and then I can test and complete the other axes.
Note 1:
The DI status (U40.04) is contradictory.
The inputs do not show as switched high.
When they are activated, they go low.
The driver interprets a low as 1, which is confusing.

Note 2:

There may be a problem with cia402homecomp.comp.
Once it has started, it cannot be stopped.
This happens, for example, when the servo moves to a limit switch.
It is not possible to move freely; the error “Home movement is still active” occurs.
This error also occurs when only one axis is referenced.
After completing the home movement, it is displayed as referenced, but can no longer be moved. The error “Home movement still active” also appears here. I will see how it behaves when I perform the home movement on all axes.

Note 3:

Since recently, I have been getting an amplifier error on the Y-axes (gantry) when starting Linuxcnc (gmocappy). The error can be acknowledged and does not reappear during runtime. 
However, this may have another cause.