Advanced Search

Sure, it's possible, a 7I92X has 34 I/O pins so could have as many as 11 normal encoders
Do you have a desired pinout?

Moved to "PlasmaC" section.

Quick update.
After some suggestions from ChatGPT, lcec_configgen worked by using the full /usr/bin/lcec_configgen command.

The resultant XML doesn't work, but it's given me a starting point which I can work with.

I've trying to create the XML for a Amsamotion EC1A-1016R-AM6 module, but lcec_configgen appears to be doing nothing.
The command appears to be recognised, but gives no output.

ethercat slaves shows my Lichuan CL3-E57H drives and the EC1A-Core, with -v option showing all the expected values, but lcec_configgen appears to do nothing. The terminal simply goes back to the prompt with no output.

This is on 2.9.10.

Anybody have any suggestions?

To avoid creating a new thread, I'll ask here.
Could you please tell me if it is physically possible to make a firmware for the 7i92 or 7i92T (I have both) with 8 full A/B/Z encoders? I don't need any stepgens at all, and the remaining free pins can be assigned as PWM.

I searched but I did not find so I write this post.
Hi all!

I'm now using the plasma more: QtPlasmaC v 2.9-238.315.

I have some strange behaviours:

1) I'm cutting a shape that I moved to <0, 0> by the conversational (subtracting 0.6 from each axis).
When I start the cut, the 0,0 turn to 0.6, 0.6... I can't measure the real cut position but... finishing the cut it goes back to 0,0 as in this video:
(investigating more, luckily it seams it's a visualization error only)

youtube.com/shorts/QHeixNg3vI8?feature=share

2) I'm cutting one shape, than I'm pressing a custom GO TO X0Y0 button that moves the torch over the last start 0,0 position, than I'm moving the torch by 60mm pressing 6 times the X left arrow (10mm each time), then I pres X0Y0 button to set the new starting position.
Sometimes, randomly, when I click CYCLE START, the Z axis movement is ignored and the shape is "cutted" in the air. To correct this I need to press and switch off the Power button, than switch it on again. I think it's not an electrical problem of my machine because the shape cutting movement occur without waiting the Z movement time... I also move the Z with the arrows befor starting cut cycle... Here the video:

youtube.com/shorts/zjP_dUaLeVU

3) Moving the X axis by arrows, I got to the right limit switch. I remember from previous version, you press OVERRIDE LIMITS in the message and it works to go back inside the limits... now... it seams to be looping in the message and can't go back within the limit because message appears...

youtube.com/shorts/i5hVDSLVbTQ


4) AND, I just saw now: is it a flip, is it a mirror?
Original:
 

Mirrored:
 

Flipped:
 

Thanks, for any advice.
These are not blocking errors, I mean, I can live with that! It's just to inform you in case you don't know.
I apologize if they where already posted, I did not find them. And thanks to all developers!!

Alberto 

Thank you! Mesa customer service is outstanding.

7I96S  + 7I85 with PktUART on 7I96S RS-485 interface

Note that sserial channel numbering on the 7I85 has changed
since old sserial channel 0 on the 7I96S has been replaced by
a PktUART, so sserial channels 0..4 instead of 1..5 are on the 7I85.

Encoder on the 7I96S is encoder 4  (same as normal 7I96S+7I85 configuration)


 

Hello,
I think I need custom firmware/bit-files for my setup.
I have a 7i96s with 7i85 db25 daughter-card, which in turn has 4 encoders, a 7i84u and a 7i73 attached. I want to control my Invertek ODE-3 spindle vfd with modbus from rs485 on the 7i96s. 

Unless I'm mistaken, the standard 7i96s_7i85d files don't feature PktUART for modbus on the 7i96s. Everything else seems to be working with them. 

It's a 4 axis mill, so if possible, I also wish to retain the encoder input on the 7i96s for a spindle encoder - (if i understand correctly there can be complications there due to muxed vs unmuxed?).

I've had a look for existing firmware, but don't notice a suitable option in the standard 7i96s package. 
I also read the below linked thread, but don't see links for bit/pin files there.
www.forum.linuxcnc.org/27-driver-boards/...dbus-pkt-pin?start=0

Would this be possible please? Any other information needed?

Gentlemen, you’ve made a real mess of things...
The topic at hand is that my EtherCAT configuration cannot be made to work on LinuxCNC 2.10-pre2.
First, there was an issue with `lcec_conf` throwing an error; then, it was claimed that this had been fixed (which isn't entirely true, though version 1.45 of the linuxcnc-ethercat from the `getset` branch seems to work correctly); and finally, the discussion turned to the inability to install `cia402.comp`.
I use the `cia402.comp` from the rodw's repository, as it has worked for me so far (the one from github.com/dbraun1981/hal-cia402 is five years old and has never worked for me anywhere).
I have no interest in internal drive homing, as I have no use for it.
I want to migrate my machine working well at LinuxCNC 2.10-pre1 to 2.10-pre2.

Todd wrote:

I'm sorry, you lost me. Versions 1.45, 1.46 and 1.47 of what software?

Ok, I looked at the page you linked to of the comp of Rodw, and I'm not sure it is even necessary. The same function could be probably achieved with just a few lines of hal logic using ordinary hal components, rather than writing a custom comp. Simply use a mux hal component to connect the commanded position to the feedback while the homing pin is true. (But there could be an issue if there is a large step in the FB position when homing is completed. I don't think that will happen but...)

Some of these guys get a little carried away writing custom hal comps for their nich uses when existing standard components are more than adequate. Which is fine and good for their own personal uses. But I don't always agree with them posting their "this is how it has to be done" tutorials and linking to their custom comp that is out of tree, which doesn't follow updates of the main system that may break them.

Homecomps are part of the LinuxCNC design and are intended to avoid (complex) custom coding in homing.c. The code in question is not designed for general use and has not been tested. But the changes made by the developers  in 2.10 has broken every out of tree component. There is a lot of pain across many users to come......

I was wrong. It defaults to spindle $0 which does not really make sense.

I'm sorry, you lost me. Versions 1.45, 1.46 and 1.47 of what software?

Ok, I looked at the page you linked to of the comp of Rodw, and I'm not sure it is even necessary. The same function could be probably achieved with just a few lines of hal logic using ordinary hal components, rather than writing a custom comp. Simply use a mux hal component to connect the commanded position to the feedback while the homing pin is true. (But there could be an issue if there is a large step in the FB position when homing is completed. I don't think that will happen but...)

Some of these guys get a little carried away writing custom hal comps for their nich uses when existing standard components are more than adequate. Which is fine and good for their own personal uses. But I don't always agree with them posting their "this is how it has to be done" tutorials and linking to their custom comp that is out of tree, which doesn't follow updates of the main system that may break them.

a {
text-decoration: none;
color: #464feb;
}
tr th, tr td {
border: 1px solid #e6e6e6;
}
tr th {
background-color: #f5f5f5;
}I’m currently developing this application, but I haven’t yet been able to publish it on the Play Store as an open test. I’m looking for users who can try it out, share their feedback, and help identify any bugs or issues that may still be present.Most of my current testers don’t have access to this type of device, so their testing opportunities are somewhat limited. If you’re interested in evaluating the app, I’d be happy to invite you. Just send me your email address, and I’ll provide you with the Play Store testing link.Thank you for your time and willingness to help improve the app. Your feedback would be greatly appreciated.
   
LinuxCncDroid is a high-fidelity, touch-optimized industrial Human-Machine Interface (HMI) built for monitoring, controlling, optical centering, and metrology calibration of CNC machine tools powered by LinuxCNC and Machinekit.Crafted natively in Kotlin using Jetpack Compose and Material 3 Industrial Design, LinuxCncDroid provides out-of-the-box support for industry-standard fieldbus topologies (Mesa FPGA, EtherCAT, and Parallel Port), featuring real-time telemetry, a haptic Virtual MPG Handwheel, an interactive 3D G-Code Toolpath visualizer, 3D probing routines, live camera crosshairs, reactive Metric (G21 mm) / Imperial (G20 inch) switching, and an ISO 230-2 metrology calibration wizard.

Hi Andy,

I actually discussed this idea with Michael Haberler about 15 years ago, and I left it alone for a long time because of the complexity involved.

When I finally took it on, it required a substantial amount of reworking across the existing code. It took several attempts and a few changes in direction before I found an architecture that worked for what I wanted to achieve.

The shared HAL approach is an interesting option. In my case, finding a workable overall concept was a major part of the effort.

It’s good to hear that this is being discussed at the meet-ups as well!