Signalers - Light Tower

[Duncan Ellison]

Hi all,

I have decided to add a tri-colour LED tower to my machine so that I can see the status from a distance and also because it looks cool (!)

Followed the guidance in https://github.com/openpnp/openpnp/wiki/Signalers and some brief input from Jason.

LEDs are being activated in more or less the correct place when running a job, but they seem to only 'blip' the LEDs on for a few milliseconds.  For reference, I have a subcontroller which takes commands like "LED T-RED ON" "LED T-YEL OFF" etc.  and have set the on and off states as True and False in the actuator.

I realize this is a minority interest, but has anyone else managed to get this to work satisfactorily?

Duncan

[Duncan Ellison]

My machine.xml wouldn't load with one of the updates (I hadn't updated for 6 months, so don't know which), it was objecting to the signaller / actuators that run the tower lights, so had to manually delete them to get some work done.

Now I can't seem to get them to work correctly again.

Do the signallers still need to be manually patched into the machine.xml and not through the UI as the wiki shows as there seems to be some (new?) functionality in Signallers that seem to set this, but it doesn't get remembered when you hit Apply?

Duncan

[Duncan Ellison]

Here's the functionality I found in Signallers :

The actuators (TOWER STOPPED / TOWER ERROR / TOWER RUNNING etc.) operate correctly when operated manually from the UI tab, but here they neither seem to work or to be remembered. 

[Duncan Ellison]

Here's the machine.xml

[Duncan Ellison]

OK, I got it now ....  You have to create one signaller for each machine state - doh!

[Darrin Taylor]

Wrong email address.

I think you may want darrin.taylor1@gmail or something like that.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/16ab2afd-8d6d-4de3-99b2-2e7ba9796074n%40googlegroups.com.

[mark maker]

This likely relates to

https://github.com/openpnp/openpnp/pull/1553

or

https://github.com/openpnp/openpnp/pull/1556

@Jan, could you please have a look?

_Mark

[Jan]

Unfortunately I can't tell: the provided machine.xml contains a single
signaler bound to job-state="STOPPED" and loads just fine for me.
However, as part of PR #1556 I removed the MachineState dependency
(ActuatorSignaler.java, line 30) which might throw an excessive elements
exception. From the PR: "The second step might break user setups in the
unlikely event, that they configured a signaler of type ActuatorSignaler
and altered the Machine state drop down to ERROR."
If you think this is a serious issue, I can revert the removal by
keeping MachineState in machine.xml.

Jan

On 03.08.2023 07:19, 'mark maker' via OpenPnP wrote:
> This likely relates to
>
> https://github.com/openpnp/openpnp/pull/1553
>
> or
>
> https://github.com/openpnp/openpnp/pull/1556
>

> *@Jan*, could you please have a look?

>> https://groups.google.com/d/msgid/openpnp/16ab2afd-8d6d-4de3-99b2-2e7ba9796074n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/16ab2afd-8d6d-4de3-99b2-2e7ba9796074n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/e6d68799-13c1-eb0f-539a-26c9b025d765%40makr.zone <https://groups.google.com/d/msgid/openpnp/e6d68799-13c1-eb0f-539a-26c9b025d765%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

>    However, as part of PR #1556 I removed the MachineState dependency (ActuatorSignaler.java, line 30) which might throw an excessive elements exception.

I remember now. Perhaps it would help, if you documented the exact steps one needs to follow to fix the machine.xml. If I'm not mistaken, one would have to search for

    machine-state=

and remove the whole assignment.

@Duncan, you also wrote:

> OK, I got it now ....  You have to create one signaller for each machine state - doh!

AFAIK this is not new. It has always been like that, i.e. it must have been the case in your older version machine.xml config. Can you confirm?

_Mark

[Duncan Ellison]

_Mark, Jan

I posted a rely to this, but it seems to be lost.

I see now that there were some, unseen by me, changes behind the scenes to the way actuators and Signallers work which probably caused the Machine.xml conflict I originally had.

I finally understood that in my case, at least, I need MULTIPLE signallers (one for each machine state) i.e. one with Actuator 'TOWER STOPPED' and Machine state 'STOPPED'  another with 'TOWER ERROR' and machine state 'ERROR' and so on.  This seems to work fine for me now.

I misunderstood the concept of 'signaller', I thought it was one entity with multiple states.

Thanks for taking the time, guys.

[Jan]

On 03.08.2023 11:13, 'mark maker' via OpenPnP wrote:
> />//    However, as part of PR #1556 I removed the MachineState

> dependency (ActuatorSignaler.java, line 30) which might throw an

> excessive elements exception. /
>
> I remember now. Perhaps it would help, if you documented the *exact*

> steps one needs to follow to fix the machine.xml. If I'm not mistaken,
> one would have to search for
>
>     machine-state=
>
> and remove the whole assignment.
>

Thats true. One can either configure the machine state dependency to
null/empty before the update (then the machine-state parameter is not
written to file) or open machine.xml, search for <signalers> and remove
all "machine-state=..." attributes in there.

> @Duncan, you also wrote:
>
> /> OK, I got it now ....  You have to create //*one *//signaller for
> //*each *//machine state - doh!/

>
> AFAIK this is not new. It has always been like that, i.e. it must have
> been the case in your older version machine.xml config. Can you confirm?
>

Yes, signales always operated actuators of boolean type which gets set
depending on job and its own state. So a single actuator per signaler is
required.

Jan

> https://groups.google.com/d/msgid/openpnp/edd62583-1809-f422-71c6-067c5382644a%40makr.zone <https://groups.google.com/d/msgid/openpnp/edd62583-1809-f422-71c6-067c5382644a%40makr.zone?utm_medium=email&utm_source=footer>.