(Solved) Probe Basic - HAL pins not being created

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.

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.

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.
 

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. 

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?

here is an example:

Lcvette wrote:

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?

Not what I'm looking for, but the connection feature is interesting and I wasn't aware of it.

The LED was just a first stab at some sort of screen indicator.  After fiddling and thinking about it I realized a Qlabel can be better - an LED takes up more screen space because you also need a label for the LED.  Why not just make the label behave like the LED would?

To be specific, I have an air pressure sensor that interlocks the machine - can't start the machine without it.  Plenty of times I've tried to start the machine with the main air valve off ('cause leaks), couldn't start the machine and it took a minute to figure out the problem.

So I want an indicator that flashes red at me when the air sensor hal input is low, and I want it green when the hal pin is high.  If the label changes from AIR LOW to AIR OK, that's a bonus but unnecessary.

No screen button required or desired - just an indicator showing the two states of a hal pin.  I could have two labels or two leds, but that takes up room and looks hacky.