Advanced Search

forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

rodw wrote:

I don't like using backports. Never have used them.
 

"I don't use it" and "I don't like it" are not substantive arguments.
The problem is that there are newer versions of the libraries in the newer release. First of all, it is about Python, in which the authors constantly change or remove something, so even relatively new programs (from a year or two ago) do not want to run, or some of their functions do not work.
However, backports repositories are optional, you can activate them, install only what you need and then turn them off again.

Hi

I do not succeed in flashing any firmware to my 7i95T mesaboard.I can ping it under adress 10.10.10.10. Its debian 13, linuxcnc should be 2.10, I replaced 2.9 to master in etc/apt/sources.list.d. and reinstalled according to post from RodW in this forum. ( I would have to look for the exact thread) Mesact lets me select 7i95t board and ip adress 10.10.10.10 in Machine. Verify board says device found at 10.10.10.10 is not a Mesa Board, not surprisingly Find IP board Results: No ETHER board found.  In terminal mesaflash (version 3.5.11) answers No 7I95T board found . Same behaviour with adress 10.10.10.1. No firmware found, I copied firmware according to instructions in window I/O Map in mesact. Thanks for any assistance

cheers geebee

 

I'm working with a TORNOS-BECHLER ROBOBAR SSF automatic bar feeder mounted on a Tornos Deco 2000/20. It's a base configuration unit — no DPL/MDI operator console, so I'm limited to the front panel (SA2 mode selector, SB1–SB5 buttons, HL1/HL2 indicator lights).Looking for general input from anyone who's operated, maintained, or programmed one of these:

• Tips, gotchas, or common issues you've run into with this feeder, the Deco 2000/20 control in general
• Workarounds for running it without the operator console
• Anything about parameter setup, calibration, or troubleshooting that isn't obvious from the manual
• Sources for parts, documentation, or people who know these machines well

I've got the full manual and electrical schematics on hand, so I can share pages or details if it helps narrow things down.If anyone with real hands-on experience wants to help more in depth — a call — I'm happy to pay for the time. Just reach out. 

It seems that its recognized as a cia402 device. at this point, with LinuxCNC open, open another window and type: halcmd show pin lcec

This will list the pins they were found. You can use them in your hal file and follow the cia402 templates.
I have a feeling you need to command your drive using a mode not supported by the cia402 component. It will need modifying and rebuilding to support it. But I can't help you there as I have no expereince. Someone else may be able to help.

I do know one user using an abb VFD but they are using MODBUS 485 to avoid buying the FECA-01 interface

I found this document:
library.e.abb.com/public/52b4831c464449e..._CiA402_Rev_A_EN.pdf

that is where I found which parameters to set to enable the ethercat module. at the moment I have:
1) set 50.01 parameter to 1 (enable the module)
2) 51.01 to 135 (set to EtherCAT)
3) 50.04 to 4 (reference is speed)
4) 51.02 to 0 (CiA402 drive profile)
and attached is the XML file. I would appreciate any hints on how to get it move the motor (I am looking for basic functions - start/stop and set the rotation speed). any extras, like spindle-at-speed signal, what is motor load etc is optional
I am looking at that manual and it is very confusing for me about the bits of command word and status word. I believe it is handled by cia402 component and I just need to connect proper HAL pins. is that correct?

It's actually quite simple to install Flex GUI and use it if you read the well thought out docs.

On the other hand adding this to the already bloated LinuxCNC with many confusing GUI's seems to be a nightmare and quite complicated.

IMHO GUI's should not be included in the main repo except for Axis so as to not drag in a huge amount of dependencies for nothing. Especially when many of the GUI's are not supported any more as the authors have moved on.

JT

If you were to install Debian Forky (aka testing), you get the 7.1 kernel. You should be able to install Linuxcnc direct but it may not be the latest version. You can install the LinuxCNC repos by running a bash script mentioned in the docs here which would be preferred as it keeps you current
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel 

Then install Linuxcnc with 
sudo apt install linuxcnc-uspace linuxcnc-uspace-dev

Anyway, that is how I would do it. The pre-release versions of Debian are rock solid in my experience. I don't like using backports. Never have used them.

I came across this issue in QtPyVCP/Probe Basic because they share the same spindle_sim.hal as Gmoccapy.

It's really not ideal to have a simulated config be non-functional for spindle speeds ≥12500rpm at the default base period of 100000ns, I know it can be 'fixed', but ideally it should work by default, high speed spindles are not rare now.

Is there a reason why instead of modifying the base period, the value of sim_encoder_0.ppr (and therefore also encoder_0.position.scale) can't be decreased?
Is there actually a reason to sample this frequently in a simulated config?

I'm naively assuming that it is because this logic predates high speed spindles being easy to get hold of, so it wasn't seen as an issue at the time?

cutnweld wrote:

Thankyou snowgoer, I really appreciate it. In the future, if you are ever fiddling with it, I have a few suggestions. One being the material list, it seems as tho I need to select material when going from a gcode part to conversational, instead of it simply remembering the last used cut chart, IDK if that is a bug or just the way it is.

I fired up my VM machine and tried this one, it pre-populates with whatever I had chosen on the MAIN screen. Whether or not a g-code file is loaded. I believe what you are saying, but if you could find the exact steps to reproduce it, that makes fixing it 10x easier.

2 I did have it freeze on a conversational drawn and nested part, no forward or reverse, however it may have been a conversational issue, I am not sure why it stopped in first place. It was on the last part and I was able to select and run from line then so not a big deal.

My first question is: Is this an old conversational file that perhaps you saved and run from time to time? The way we did conversational Block previously, I am not sure reverse run would have worked because it was variable based and used a lot of math, etc. I think it also used sub-routines. So reverse run may not have been possible in this instance. Before Phill stepped away from the project, he made V2 block which essentially spelled out the g-code instead of using the aforementioned method. I just tried and reverse run did work when I paused in the middle of a cut.

It did highlight a bug that I cant seem to array a circle for some reason, they all have the same origin, so I will have to take a look at that when I get some time. The other shapes seemed to array just fine.

Could you share the file you are referencing?

3 Another conversational thing, again this may not be practical to change, but if you ever rotate a part then the XY moves, say you have a part in on XY zero on bottom left corner, rotate it 90 degrees in conversational, the bottom left corner is now going to be a random -XY number. Again, not a big deal, we have used it this way several years, just FYI. If after a rotate it was bottom left XY0 that would be, well, you know! Thanks again for your efforts and for the great program!

I think it does what you're asking for. But again, without the g-code file it's tough for me to tell. I have a test file I use for a lot of things, and the origin stays the same. I put it at X0Y0, and then rotated about both Shape and Pattern, and the origin stayed at the same place. That said, how it rotates is different between Shape and Pattern. Which if you are just rotating one thing, it can be a bit confusing.

Conversational was made as a quick and dirty way to do simple things at the machine and wasn't really intended to be the end-all-be-all CAM solution. Just to temper expectations a bit, that's all; sometimes it's best to re-post the cut file from the native CAM.

All of that said, I'm happy to work through bugs and consider things like this as time allows.

Nobody knows  you VFD so you need to work it out yourself, it seems there is a syntax error in your xml and it reports the line number.
Sharing your xml file now you have  made some progress would be helpful. as we are flying blind
I suspect you will need to command it more like it was a servo except use a mode that commands RPM (velocity) not position 

Why don't you just add it to the master branch? The disjointedness of this project is baffling to me sometimes. Navigating this mess as a new user must be an absolute nightmare.

Have you reached out to Tormach for this? I know they had released updated servo configuration files for this issue at some point, I am unsure if it's after when this tread was created or not.

They haven't posted them but I have seen them on the FaceBook group(s) in the files section, also I made a pull request on their right to repair github to add all of them so people like yourself have access to them but they have not merged it as of yet.

Thankyou snowgoer, I really appreciate it. In the future, if you are ever fiddling with it, I have a few suggestions. One being the material list, it seems as tho I need to select material when going from a gcode part to conversational, instead of it simply remembering the last used cut chart, IDK if that is a bug or just the way it is. 2 I did have it freeze on a conversational drawn and nested part, no forward or reverse, however it may have been a conversational issue, I am not sure why it stopped in first place. It was on the last part and I was able to select and run from line then so not a big deal. 3 Another conversational thing, again this may not be practical to change, but if you ever rotate a part then the XY moves, say you have a part in on XY zero on bottom left corner, rotate it 90 degrees in conversational, the bottom left corner is now going to be a random -XY number. Again, not a big deal, we have used it this way several years, just FYI. If after a rotate it was bottom left XY0 that would be, well, you know! Thanks again for your efforts and for the great program!

Thanks — that's very helpful. Agreed on not mixing Intel's Ubuntu-built package into Debian; "installs but might be subtly unstable" is the worst case for a machine running multi-day jobs. I hadn't understood backports were already that far ahead. linux-image-rt-amd64 is there, so I'll stay on Debian 13 and take the kernel from backports.

That moves questions elsewhere:

Does the IgH master still build its native NIC drivers on a 6.18 or 7.x kernel? ec_igb and ec_e1000e are patched against specific kernel versions and have historically lagged mainline.

Do the native drivers still compile on a recent backports kernel, or is everyone on the generic driver now?
If generic — what does it cost in worst-case jitter at 1 kHz? and is generic-driver EtherCAT running in production machines, or is it considered bench-only?

Anyone here Amston Lake / Alder Lake-N (x7433RE, N97, N100) with LinuxCNC?