Advanced Search

I have had a bit more time to work on the machine now that I have put my tractor back together and it is out of the way, I have mostly been messing around with the gear shifting program. It is the one RotarySMP used, I have found that the program had been forked for a MH600e which is more similar to the setup that I have so that is what I am using now. I have been able to get the programs simulator to try to shift the gearbox but i havent figured out how to add the cam position switches to the logic so it doesnt know where it is going it just moves the cams.

Replied to other topic with seemingly same content.

Mesa 7i76EU comes with firmware loaded and ready to run, just use the included PncConf or MesaCT wizards to make a configuration for your machine.

I have no power for the last 3 days so using the phone makes it dificult to quote stuff with this editor, but in short:
-i have PlasmaC in daily use in over 10 machines, users got used to occasional stops and are OK with it, luckily rareley happens, i think it is 2.8.4 version.
-i have probably over 20 machines using the old hal THC i cobbled together, in daily use, never fails
-i had 2 machines plus mine using QtPlasmaC, had to switch back to PlasmaC. This was a year or two back, so i will give this another try when i get a chance.
-you and Phill are doing a magnificent job of supporting and fixing this, instantly, utmost respect
-PlasmaC has 4 or 5 ways of disabling the THC, most are useless, except VAD, and void lock sometimes. Right now i can not think of any other valid use case. BTW default should be at 60-70%, not at 95%.
-what should i monitor for the issue where the torch keeps going down till float switch triggers during cut, happens often and ruins the nozzle. More often in QtPlasmaC but that might be just luck
-what should i monitor for the issue where the machine moves to a cut position and just stays there? This happens sometimes even when doing a manual cut where pressing F9 shows the machine running on screen but nothing moves. DRO does not change, machine state does. Again this happens a lot on QtPlasmaC, do not recall this happening on PlasmaC so might be a QT thing. I think these are two issues, one during cutting where the Z axis does not retract properly during normal cutting, and the other stated above where nothing happens.
-i think i have an old config for QtPlasmaC on a laptop for my machine, i can upload that if you think it might help.
-i absolutely have no issues with intelectual property, i do and will post everything i do personally, as can be seen from many posts here, i am strictly Open Source everything, and i did reject any job requiring me to sign an NDA
Ooops, not very short

Can you help me with mb2hal?
Here is my old setup for vfdmod file for Danfoss VLT FC-51
There was only a few commands cw, ccw, stop and frequency.

I use N100 miniPC with good success. Anyway.

Yes, you have a Realtek network adapter.
 

Please install the r8168-dkms driver
"sudo apt install r8168-dkms"
 

Honestly one of the most terryfying things I have ever done to a machine. Point of no return reached. (Even thought I labeled all the componentens and still have the drawings of the original setup, so I could technically put everything back)

Now I can start to layout the new components in the control cabinet (with cartboard cutouts)

 

 

Thank you so much.
I had been using N100 PC (or such Atom CPU )  for CNC machine, but this time, I installed LinuxCNC to Dell small PC ( 4 core i5 CPU ) just because of having smaller latency and more CPU power.

I have attached lspci - k output. 

if calculations are fitted in the servo thread time(which should be 250u as industrial standard) it should be nice to see or try something new ... for 7 phase generator is lcnc waiting many years and it is step to its adulthood

Michel told me to update his code but from my point of view If anybody on anyhardware will want to use it .. it will me close to imposible create a rt stuff for calculations ... I think it has to be splitted to rt and non rt part which will buffering each other for reaching as small as possible servo thread times

I am not expert in that at all...

Posting here with some pictures and any stylization is hell, trust me ...

it looks pretty ... reduction of any jitter in the rt system is more than welcome ... pll is very critical stuff for system and it is nice to see its major improvement 

Which driver for network card are you usig for testing it for now? jittering can be produce by generic drivers too i think

I saw it was merged in the master ... we will wait for scott to public new feed or version? 

I've ordered a MESA 7i76U, should get the machine up and running once configured.

I'm going to park this one.

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...