(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.image missing /media/kunena/emoticons/wink.png

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: