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 Zuercher 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!

Hi Rob,

Thanks for your message and your offer to help with testing and development! Your Citizen L16 sounds like a great candidate, and your experience with sliding head lathes would be very valuable.

I’m currently in California and will be back in Europe on 13 November. Given the complexity of the project, I’d suggest a video or phone call to discuss the machine, its existing hardware, and the requirements for the retrofit.

I’d be happy to support you with integrating the new system into your Citizen L16. Testing it on a real machine and getting your feedback would also help us develop and refine the functions needed in practice.

Let’s arrange a suitable time for a call.

Best regards,
Daniel

Goooood morning/afternoon/night!
So after tons of hours of working with colleges we had to drop linuxcnc core because of hundreds of limitations and we have to write eveything from scratch. I can explain why and how this soft is done if you are intereset but for now some pictures and a video of the whole new parser, 90% $iemns compatible (also ISO mode compatible), HMI is based on same UI for operator familiarity but i added several "always i wanted" features.

Here we go: jerk controlled movements, feed blending, PLC codesys based making a toolbox, up to 31 axis (why? because i just wanted to..cpu and ram makes the limit), hmi can run on separate pc if more power is needed, multithreaded realtime subsystem running in xenomai (migrating to jailhouse soon) (actually rtapi from linux cnc has a huge design problem, it only runs on one cpu core and each thread has less priority than the previous initialized, that was the weakest point found to make as drop it completely), work offsets, tool offsets, machine data with access protection, multichannel (up to 10 right now, why? because i wanted to.. again, cpu is the only limit) with synchronization (waitm commands plus others), up to 10 mode groups (several channel can group in different mode groups so, going to jog mode makes all channel from same group change to jog, same for mdi, auto, etc..)


youtube.com/shorts/kW06KXbYc_0

Best regards, enjoy!


 

I think I've found a solution to this odd behaviour:

Link to old topic...

I would be grateful if someone could test and
replicate the solution.

Best wishes, Jan

Hello everyone,

after all these years, I finally seem to have found a solution to the problem described in this thread.

I should mention that I'm not really a programmer, so I investigated this with quite a bit of help from AI. Essentially, an amateur debugging LinuxCNC with AI assistance.

The original problem was that when jogging an axis using the arrow keys in AXIS, moving the mouse pointer into an embedded GladeVCP panel and releasing the key could cause the axis to continue moving.

I reproduced the issue in an isolated LinuxCNC 2.9.10 simulation and added some debugging output to AXIS and GladeVCP.It turned out that GladeVCP correctly receives the KeyRelease event, but the forwarded event does not always reach AXIS.

The solution appears to be surprisingly simple:

In lib/python/gladevcp/xembed.py, inside keyboard_forward()

add d.flush() immediately after fw.send_event(fe):


fw.send_event(fe) d.flush()


I performed an A/B/A test:

- With d.flush(): Jogging stops correctly.
- Without d.flush(): The original problem returns.
- With d.flush() restored: Jogging stops correctly again.

I also restored the original LinuxCNC 2.9.10 xembed.py and applied only this single-line modification. The fix still works.I tested repeated jogging and switching between axes, releasing the arrow keys while the mouse pointer was inside the GladeVCP panel. So far, the problem has not reappeared.

Please note: All testing was done in a simulation, not on a real machine. This is not a safety validation.Since I can`t guarantee that this is the correct upstream solution, it would be great if someone familiar with the XEmbed implementation could review the change.Maybe this little fix can finally put an end to an issue that has been around for quite a few years!

I attached the modyfied xembed.py file.

Best regards,

Jan

hi, this is very grate news,

i am in the UK,

i have a Citizen L16 laying around (did offer it on her for sale etc) its waiting for a new life as the old control boards are dead.
i'v done many linuxcnc retrofits over the years of milling & Turning for the sliding head iv been waiting for someone todo this much needed addition work. so thank you for taking this on.

i have other sliding head lathes too and multi axis spindle machines so i am willing to retrofit the old Citizen L16 and help you develop this along its road path as is needed from a lathe point of view and usage and test and help you add functions to it.

let me know how how i can help out etc

Thanks to all for reading, found I guess everything so far.

Regards
Roman