Advanced Search

Oh, sorry. More of a hey, this is what I'm working on. Decided to leave linuxcnc alone, and build just a UI/Setup interface with some network admin stuffs.. still in it's infancy, but I'm slowly pecking away at it. Have Motion, and been narrowing in on probing and MDI functionality. once I get this all stable then I can go back and gut all the overwhelming useless buttons, and clean up the UI clutter in general.
Stubbing out some stuff for etherCat for future upgrades if I make it that far. lol

network.. i won't go down that rabbit hole, but, employer, son and his game server, staying in a motel, staying in place with network shady people... ? who knows..

here is an example:

  
This is my first time building something like this cnc plasma table so looking for opinions on what I can improve before wiring everything.
7I96S
THCAD2
24v 16Amp psu
5v 4 amp psu
dm556 drivers (x, y1, y2, z, a)
5v relays for arc and torch control
8 opto isolators for limit switches (2 x, 2 y1, 2 y2, z, z touch)
e stop
If you room for improvement please chime in and let me know before I attempt to not make a rats nest of wires. 

ok so blinking led is possible when active that functionality is already there. you can use signals and slots to connect widgets, not everything has to be done with rules, ie if you have a button you can run a signal and slot to an led to have it turn on and off, flash, stop in on state or stop in off state. perhaps this is what your looking for?

Just to be clear, not blinking 'buttons', but blinking indicators - Qlabels.  Not a control - just an indicator/display widget.

I don't want to become a dev of anything.  I just want to machine stuff, but I have some personal preferences about user interfaces that compel me to try to get what I want despite my galactic incompetence at computer stuff.

Having said that, I'm happy to help if I can.  Just know that I have zero background in computer code.  I have no friends who code or are 'computer people' for a living or hobby... nobody in my circles did it growing up.  I have no common language with people who write code.  I use computers daily, but have no meaningful understanding of what's under the hood beyond the superficial.

I feel like I'm talking to a group of nomadic horse warriors who grew up in the saddle and most have PhDs in equine medicine...  They're speaking the same language I do, but everything they say is laden with a horse-culture undertone, jargon, and shared experiences.

And my total horse experience is seeing a stick-figure drawing of a horse, once. 

I will try to take a look after work this evening.

In the meantime are you able to upload a backup of your configuration that is created by the BACKUP button on the SETTINGS tab of the gui?

can you give me an example of what you are trying to do?

The machine status label would be one example:

• Label field
• Responds to three machine states (could be more, 3 for this ex)
  • Program-stopped
    • Text: STOPPED
    • Font: white
    • Background: Black
  • Program-paused
    • Text: PAUSED
    • Font: white
    • Background: Yellow/black blinking
  • Program-running
    • Text: RUNNING
    • Font: Black
    • Background: green steady

All of those could individually respond to the appropriate status: data source (not HAL pins), but I cant figure out how to get the paused state to blink or combine all three states in one widget.  Which led to AI and .py file edits, which we don't talk about anymore.

Example 2 is the HalLedIndicator

• Hal pin state 1: green, steady (or whatever)
• Hal pin state 2: red, blinking (again, color doesn't matter)

Since the off-state LED color is hard-coded black, I was trying to use widget rules to set the two appearance states based on the hal pin (bit) value.

I can see hal pin widgets becoming a nightmare, but if you can limit the widget rules to react to the hal pin state and not drive any hal data/value, I'd think that would be less likely to end in disaster.
 

i think some widget rules werepurposefully left out because hal widgets are typically driven by their pins and if you try driving them with rules you start getting conflicts.

can you give me an example of what you are trying to do? there is likely a better way to work around it.

we could possibly add some rules functionality to pure user input type halwidgets such as the spinboxes, checkbox, groupbox, but the others would be a nightmare i think and would end up being more dangerous than helpful.

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.