Advanced Search

Lcvette wrote:

hows it coming?

Starting over from scratch so I don't accidentally copy some edit/widget/setting which relies on one of the verboten modified .py files.  It's likely going to be a while before I can get this where I want.

Still can't get widget rules to work on hal pin widgets - there doesn't appear to be a data source or channel in the widget rules for hal widgets.  While I thought I remembered seeing a complete list of channels in the qtpyvcp user docs, all I can find is a short example list:

Data Source: A data source is something the provides data channels. Examples of a data source are  which provides machine status updates, and  which provides data on the tools in the tool table.

Data Channel: A data channel provides a single set of data which can be used in the rules expression. Examples of data channels are  and .

I've tried exported_hal:nnnn and hal:nnnn, but neither of those make a connection.

The LEDs I was attempting have a hard-coded 'off' state color (black), and I was trying to get a OFF=green / ON=red appearance.  Superimposing two LEDs on top of each other didn't work as I couldn't trigger one to be transparent in an off state.  I wound up with two LEDs next to each other - green & red - but that just looked dumb and I abandoned LEDs for QLabels.

I can set a QLabel OFF state color as well as ON state... make it look like the two-state green/red indicator I was hoping for.

The problem I got stumped on, and which Claude worked out leading to the forbidden .py files, is a three-state Qlabel indicating machine state: STOPPED/RUNNING/PAUSED.  I've found that a macro or subroutine can get hung or an error, and it's hard to tell if the machine is running but waiting for something, paused, or actually stopped. An indicator clearly displaying the machine state would solve that.

So that's the next hurdle once I re-do all the basic edits.

We just updated our table to version 2.10-016.084, Now when we pause mid cut the torch simply raises up and goes into reverse, backing along the cut path alll on its own. It does not pop up with the FWD and REV buttons that it used to. That does not work to well for us sometimes.....

parallel port is supported, you can already upgrade and use parallel port, I did not understand what Tommy's comment was referring to, my bad...

then nevermind we do not have testers for these very old drivers, we will cleanup...

Moderator tommylight indicates that no 8255 is installed, instead, there's just a parallel port?  I'm using the "native" parallel port on the Compaq Presario,  Running dmesg on the rtai kernel says:
parport_pc 00:07 reported by plug& play ACPI
parport0 PC-style @ 0x378 irq 7 [PCSPP,EPP]
lp0: using parport0 (interrupt driven)

This could mean there is a version of linuxcnc kernel that already supports a "native" parallel port.  Certainly if there's an ISO image that already supports a parallel port my hardware setup isn't going to have the desired affect of testing against an 8255. 



 

hows it coming?

5_Zylinder wrote:

The problem arises when the cam limit switch (Pin 28) is triggered: the motor shuts off, but the carousel ends up positioned between two pockets. The motor needs to rotate another 180° so that the cutout aligns with the sensor.

Which version of "carousel"? The newer version supports a slow-speed search for the index marker. 
Settting decel-time and align-dc should activate this behaviour. 
linuxcnc.org/docs/stable/html/man/man9/carousel.9.html

If the sense of the index marker is wrong, then you can typically connect to the inverted HAL input signal that most drivers support. 
For example Mesa cards have pins like hm2_5i24.00.7i64.0.0.input-00-not which is an inverted version of hm2_5i24.00.7i64.0.0.input-00
 

Hi
Meanwhile, there is Xenomai3 and Xenomai4 support in master branch.

Details:
github.com/LinuxCNC/linuxcnc/issues/3878

Prebuilt Kernels and Linuxcnc 2.9.10 back-port for Xenomai4:
github.com/hdiethelm/xenomai3-linuxcnc
github.com/hdiethelm/xenomai4-linuxcnc

For me, it works well and I fully switched to Xenomai4.

Hi All
Meanwhile, I fixed Xenomai3 support.
Additionally, I added Xenomai4 including support Ethernet mesa cards.

Details:
github.com/LinuxCNC/linuxcnc/issues/3878

Prebuilt Kernels and Linuxcnc 2.9.10 back-port for Xenomai4:
github.com/hdiethelm/xenomai3-linuxcnc
github.com/hdiethelm/xenomai4-linuxcnc

Is someone using Xenomai3 actively? Xenomai3 support for Ethernet mesa cards is available in a private branch but not (yet) merged.

Rather than LUT5 look at using a match_8 for each gear.

Alternatively, a mux_generic with 6 bit inputs could provide the gear number, or a pair of them could provide the speed limits.
Your HAL file would only need to define inputs for the valid gear positions, not for all 64 possibilities.

The latest version of the Python Tooledit widget might suit you better, as of this commit it looks like it can run standalone.

github.com/LinuxCNC/linuxcnc/commit/fc24...a518b07987c9e20fd30e

I don't recommend this kind of fun to anyone, but LinuxCNC with Trixie can be installed and run from an 8 GB partition.
For a standard xfce4 installation, 16 GB is enough.
I'm talking about just LinuxCNC without any CAD/CAM or other utilities.
Of course, today it is difficult to buy such a small disk and there is no technical or economic justification for it, but it gives you an idea of ​​how much is needed.

40 GB would be plenty, if you could run gparted and move your partitions around making space for a third system, and install debian trixie, maybe with xfce, we could try and develop support for pci 8255 on the preempt-rt kernel, and you could test it out.

preempt-rt kernels are easy to install,
sudo apt install linux-image-rt-amd64 linux-headers-rt-amd64
Is all you need for that, you will have to run in place, so you want to git pull the repo, and build locally uspace and run in place.
Once you got that working, let me know, and I will prepare something for you to test.

Sure thing, I'll try and put one together in the next couple of days.

I would suggest qtdragon-hd with a 1080p touch screen. Several probing methodologies are included.
Linuxcnc includes a  (large?) number of Sims.
There is an extensive thread about Ethercat jitter which you will see died out once issues were resolved.
forum.linuxcnc.org/ethercat/58103-ethercat-random-jitter-fix
Part of the solution  is tuning the system for RT performance and it was comforting for me to see it acknowledged that my tuning  methods were needed. I might add, the same applies for mesa network cards.

The fundamental difference between mesa and Ethercat is that mesa requires a dedicated point to point railway track. Packets hop on the train and get off at the end. Then packets get on the train and go back to the PC.

Ethercat is more like a streamlined bullet train which goes past a number of stations (slaves). Packets get on and off at each station (slave) without the train stopping. Hence why I say its more efficient.

The other difference is that mesa has pncconf to build your config and ethercat need you to build your config from a template just like I had to do on my first machine that used a Mesa 7i76e that was not supported by LinuxCNC at the time.  Having a similar Ethercat dsonfig tool is unlikely. It hard enough to do for the family if mesa cards, imagine how hard it would be with thousands of devlces, some of which are rarely found on a CNC machine. Then ask a machine to home itself without LinuxCNC's knowledge or control....

It seems to me the lawn is really an XY plane with no motors on the axes and the tyres follow a tangential arc and provide the drive.
I think the new motion.interp.heading pin in master branch could solve this. You give the mmachine fake XY g1/g2/g3 moves including the arc at the end and tell the tyres (eg A axis) to follow the heading. If the front and rear wheels need to follow differing arcs on a turn, you might need to adjust/scale the heading using a real time component. Perhaps the spindle speed (S command) might set the rpm on the wheels.

I think with this new feature, solving your problem is a lot simpler than you think.