gmocappy clock

@Hans

IMHO we should leave this as VCP, as so the users may use it in different GUI and also on different places.
You see, both of us have already different use for nearly the same panel, so it might well be the better idea not to include in GUI as this is faster to be modified.

I like the idea of lubrication distances etc, but I do like also hardware button and key switches etc. That's why I made hal pin for reseting the alarm. On machines used in production, I imagine the operator should not be able to reset the alarm, but the man who does the maintenance, has a key and is able to reset the alarm.

The counters part of travel distance since lubrication, total travel distance etc. would be good on the settings page, as more information, as better. And in custom_box_4 just the most relevant 4 ones.

If you do integrate also a part counter, that would save me time, as I was willing to do that too and we will need a short documentation.
After that, I can push the panel to master or 2.8 so it will be available to all users.

I do not think it is possible to use the Hal file twice, but I do not see a problem in making all connections in one file.
For that you will need to find the order they are loaded, as it is not ensured that they are loaded in the order of the INI entries. Also TwoPass will not take care of this hal file neither of the postgui hal file. Double entries should be avoided.

Norbert

Norbert

newbynobi wrote:
IMHO we should leave this as VCP, as so the users may use it in different GUI and also on different places.

Exactly my opinion too.

newbynobi wrote:
On machines used in production, I imagine the operator should not be able to reset the alarm, but the man who does the maintenance, has a key and is able to reset the alarm.

But you can enable a password protection to go so the settings page, so the user won't be able to reset this

Okay I can have a look on integrating the part counter.

newbynobi wrote:
I do not think it is possible to use the Hal file twice, but I do not see a problem in making all connections in one file.

Sorry I think I expressed myself not clear enough. As VCP I was meaning a glade file.
In detail getting the object of the glade file from outside the gladevcp call

So with an entry like this in the INI file

The problem of getting a builder Object from an other glade file will be to get the corresponding builder Object first, I think it does not make sense. Better just use two python and two hal files.

To get the part counter signals you will need to integrate a hal status object in the glade file and get from there the signal, or you make a pins and connect that ones in the hal file to the halui.program.is-running and halui.program.is-idle

Running after start, may get twice high, as paused is also possible, so count new part only if idle is high or better if paused is high do not count again until idle gets high

Norbert

It took me a little bit to find the time to try it out, but it works like a charm!

biqut2 wrote: It took me a little bit to find the time to try it out, but it works like a charm!

sure, this is gmoccapy :laugh:

@Norbert

I played a little bit around with the hal status objects and callbacks to get ready for the part counter.
i made a version that don't need hal pins for the running state to make it easier to integrate.
I implemented two variants using the example of the programtimer.
The question is which one would you prefer respectively is the more efficient way?

a) has the more compact code and b) is more callback based.
I think I would prefer a).
Then I would like to modify the counter to eleminate the HAL pins that can also accessed internally. Do you agree to that or dies teh HAL pins have some avantages? Of course the custom pins like lubrication interval still have to exist.