Advanced Search

github.com/linuxcnc-ethercat/linuxcnc-ethercat/pull/465

new PR with pictures, which I don't want to repost here, look at explanation on github, I'm available for questions. code has been tested, everything should be way better now, and possibly can even use not so good hardware and achieve decent ethercat no grinding.

Hi all,

I’m setting up a Mesa 7i76E (Ethernet) with a single 7i76 smart-serial I/O board on Debian 12 / LinuxCNC 2.9 and appear to be stuck due to missing FPGA firmware.

LinuxCNC installs and runs fine, PnCconf completes, and the board is reachable over Ethernet, but field outputs never work:HAL signals link to hm2_7i76e.0.7i76.0.output-00halcmd show pin | grep 7i76 returns nothingdmesg shows no smart-serial / 7i76 detectedEstop / stepgens work, but no field I/O activity/lib/firmware/mesa does not exist, and I can’t install linuxcnc-firmware-mesa because the machine is offline and buildbot appears to be down.

I’m looking for a known-good firmware file for this setup (likely 7i76e_7i76x1.bit), or a working mirror / source for Mesa firmware on LinuxCNC 2.9.

Any pointers appreciated — happy to provide logs if needed.

 Thanks!

Tim.

Hey guys!

Hopefully I'm not banging a beaten drum here. 

I am on the very cusp of finishing my build with the MESA 7i76eu, only to find, like other by the sounds of it, that the boards do not come flashed with firmware. Can someone please help me out? this was discovered when navigating to linuxcnc_2.9.3-amd64.hybrid\firmware to find nothing in the folder. 

Please let me know any further information required, and any assistance would be greatly appreciated!

Happy new years!

Tim.

tommylight wrote:

From what a vaguely recall, i did some test and had no success of pinpointing it.
This sort of issues are lingering on from PlasmaC where it would run several cuts then stop at random and do nothing, requiring stopping the machine and using "run from here" to continue.
PhillC did find the issue but apparently not the exact source of the issue, the Z axis would not retract to set height and remain waiting, did fix it to a certain extent where it was very usable and happening rarely.
QtPlasmaC has another similar issue, where running a program would start, got to pierce coordinates and wait there indefinitely despite Z axis being at the correct height. This happened in PlasmaC about once or twice in a full days work, on QtPlasmaC happens way more often, sometimes 3 to 5 times per sheet.

I have not experienced this behavior on a physical machine, however I can reproduce similar in my QtPlasmaC Simulation environment. In my case, it happens when eoffset movement would exceed the available range of travel (usually in Z). I have to deliberately force what I consider to be unrealistic values (but may not be for every table/setup) to trigger it. If you encounter this again, please check the following HAL pin and report back:

If this pin is TRUE, that may explain what is going on. My recent changes to automatically adjust probe height based on material thickness made this more visible. I plan to add some bounds checking in the component with regard to eoffsets, and likely will also monitor the aforementioned pin a general catch-all fault condition.

All this is way past being important, i did voice my concerns during the development about not implementing useless features into it and PhillC ignored most of it to the point that i recused myself from participating anymore, it was disheartening to see:
-PhillC sabotaging his work by implementing useless features, always, always requested by users with a single plasma machine and mostly no or little experience
-my complaints being ignored, while i had over 15 machines in daily use

With regard to your broader concerns, I am not certain which specific changes you are referring to, but many valuable contributions have come from users with only one single table. It is relatively uncommon for contributors to be building machines commercially, and practical feedback from small shops has historically been an important part of Qt/PlasmaC’s evolution.

-my input about the functionality being ignored completely, like : float switch MUST react and stop the machine even during jogging, this has ruined many torches and would have ruined much more if they did not have magnetic holders.

This functionality is in the PlasmaC component. The float switch (along with breakaway and ohmic) inhibits jogging when the machine is Idle.

github.com/LinuxCNC/linuxcnc/blob/2078bd...ts/plasmac.comp#L908

Excerpt (sensor_active is the result of if(breakaway || float_switch || ohmic_detected)):
Appears to be in both 2.9 and 2.10.

-UP/DOWN/ARC_ON LED's on the main screen MUST be usable even while not cutting to check standalone THC's like Proma

I've never seen this request but it would be straightforward to implement. I'll add it to my list of upcoming changes. Initial thoughts for criteria would be Machine On and Idle (not available when the GUI is off, or if the machine is paused).

-seeing all the effort made by PhillC and later you going to waste as PlasmaC and QtPlasmaC got so bloated and so unreliable that i had to stop using QtPlasmaC completely, and actually thinking of slowly moving the remaining PlasmaC machines to my old hal THC stuff, that never fails, ever. Yes, PlasmaC is usable and mostly reliable
-etc etc
-

I disagree with the characterization of PlasmaC/QtPlasmaC as bloated or unreliable. There are multiple real-world installations running successfully, including commercial operations.

Sorry Snowwy and Phill, but i have discussed this before with both of you, even on the phone, so to recap, this is not fixable, must be started over.

I was not trying to pick a fight.

I was not privy to you and Phill's telephone call(s), but in fairness to both Phill and myself, we've both asked you to post a backup of your configuration to try to help pinpoint the root cause, several times. If I recall correctly (not always reliable ), I even emailed you on the side asking for it in case you weren't posting in fear of leaking any sort of Intellectual Property.

As a developer it's not that I don't believe you're having an issue, it's that it is insanely difficult to pinpoint a cause and try to fix it when we are unable to duplicate it. This thread, and the changes made to the component are proof that your concerns were not just brushed off.

There are times like the recent PlasmaC issue I closed out where it was, in fact, the user's configuration that was causing the issues...

Unfortunately Vfdmod is no longer maintained and isn't really a good option for new installs. It was a bit of a pain but I switched to mb2hal. Between the documentation and a few examples I was able to figure it out with some trial and error. I suggest switching to that.

Hello!
Can anybody help me out with this step by step? (I'm not a Linux user)
I have my old setup, but i don't remember how to add Vfdmod to the LCNC, to see the pins and other.
I have now a Buster system with LCNC 2.9.7 and have a "not found file/directory Vfdmod" message.
All old links not works... How to compile it and from where and which file I have no clue...

Progress... so I found this:  forum.linuxcnc.org/38-general-linuxcnc-q...ponent-help?start=10

And that is just what I wish to do; it even works. So now all I need to do is figure out what I did different.
Attached a working example for reference.

Wow, this could get interesting, having to reference hal pins by pointer...

I celebrated too quick 

It compiles without a complaint, but trying to load it with loadrt beam_pullmax throws:
beam_pullmax: dlopen: /usr/lib/linuxcnc/modules/beam_pullmax.so: undefined symbol: y_down_slow

Yes, just use whatever powers the 7I96S +5V

Are you using Trixie? This might be something to take to the debian-user mailing list. I currently have that same problem with every single Debian Trixie install, except all these do not have LinuxCNC. My LinuxCNC is still on Bookworm, that did not have that problem.

I've been meaning to raise the issue on Debian-user but have not yet gotten to it.

I don't think the precision is an actual issue because for both spindle synchronized moves
and spindle orient, index is used so the spindle angle is zeroed before the operation.
This means that you would normally not see a significant loss of precision in the small
number of turns needed by these operations.

Can the EL5151 provide integer counts? If so, they could be easily converted/dewrapped to
a LinuxCNC hal float (which is 64 bits)
 

Was able to successfully run the Motion Studio software to reprogram the ENA input so the drives are disabled by default.

To wire the enables in parallel, a single 5V step/dir pin may not have enough current

Are you suggesting an separate/external 5V power supply for the ENA isolated output? I'm using a HDR-15-5 to power the 7i96s right now. Can I piggyback off that?

Well, I found the reason why this is not an issue: for a long time now, floats have been internally implemented as 64bit double precision, not the 32bit single precision that I assumed.
Not sure how I missed that, sorry.

Yes, resetting the counter/position on the index pulse would mess with the ddt and I am pretty sure also with the spindle synchronized motion.
The EL5151 can provide the period between pulses (or pulse frequency), which can be used to calculate the speed, but getting the correct sign of the speed is a bit annoying.
I just found out about the HAL component generator, which looks like it would make proper signed speed calculation from the raw counter value quite simple, I might try that.

The ddt approach seems to be the one getting recommended most though, so I am still surprised that I couldn't find any mention of issues related to that in combination with the float precision.

I still don't see any way to solve the issues related to the precision of the float position, as that seems to be inherent to the spindle component as it only takes position as float.
As an example:
If a spindle runs at 3000rpm for 8h (which may be somewhat realistic for a long manufacturing day), it gets to 1,440,000 revolutions, which are represented as a float value. At this point, the absolute resolution of the float is reduced to 0.125, or 45° of spindle angle, independent of the (likely much higher) encoder resolution. Isn't that a potential problem?

I am just a hobbyist who will likely never run into that issue, but it would be interesting how this is typically solved for more professional setups with long run times.

I tested it with an IceBreaker board via RS485, but it makes no difference.

for the VFD-Simulation, a USB Modbus adapter is connected to the PC, along with the Python script from above.