gmocappy clock
Thanks for your additions.
May I criticize you python code?
Do not use:
lbl_text = "%.3f m" % (travel)
lbl_text = "{0:.3f} m".format(travel)
Both are working formats, but the recommended one will it make more easy to transfer later to python3. And it is also faster and will not cause strange errors if you use tupple or list objekcts.
“The formatting operations described here exhibit a variety of quirks that lead to a number of common errors (such as failing to display tuples and dictionaries correctly).
Using the newer formatted string literals or the str.format() interface helps avoid these errors. These alternatives also provide more powerful, flexible and extensible approaches to formatting text.”
From Python Docu.
I will use part of your code
I will use my timer panel on custom Box 4 and you travel/counter panel on the setup page.
Thanks for contributing to linuxcnc and gmoccapy.
Norbert
Please Log in or Create an account to join the conversation.
Shame on me but I like C-style formatting
Do not use:but use:lbl_text = "%.3f m" % (travel)Both are working formats, but the recommended one will it make more easy to transfer later to python3. And it is also faster and will not cause strange errors if you use tupple or list objekcts.lbl_text = "{0:.3f} m".format(travel)
I will use part of your code
I will use my timer panel on custom Box 4 and you travel/counter panel on the setup page.
How do you want to integrate it? Leave it as a VCP or make it part of the GUI? If latter please make it selectable, as the space on the main screen is valuable.
I think I'll add
- counters for "travel since lubrication"
- an alarm display on Box 4 and
- a reset button on Setup page when lubricated that resets the counter and alarm display.
Similiar to your alarm by time but without creating alarm and reset pins.
By the way: Is it possible to have multiple VCPs controlled by one python and one hal file?
In this example: Having only counter.py and counter.hal and two VCPs - one in Box4 and one in setup tab?
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Exactly my opinion too.
IMHO we should leave this as VCP, as so the users may use it in different GUI and also on different places.
But you can enable a password protection to go so the settings page, so the user won't be able to reset this
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.
Okay I can have a look on integrating the part counter.
Sorry I think I expressed myself not clear enough. As VCP I was meaning a glade file.
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.
In detail getting the object of the glade file
self.lbl_running_time_prog = self.builder.get_object("lbl_running_time_prog")
So with an entry like this in the INI file
EMBED_TAB_NAME = Timer
EMBED_TAB_LOCATION = box_custom_4
EMBED_TAB_COMMAND = gladevcp -x {XID} timer.glade
EMBED_TAB_NAME = Counter
EMBED_TAB_LOCATION = ntb_setup
EMBED_TAB_COMMAND = gladevcp -x {XID} -u counter.py -H counter.hal counter.glade
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
It took me a little bit to find the time to try it out, but it works like a charm!
sure, this is gmoccapy
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
I like the option you choose without the hal pins, as it makes it easier for users, as you mentioned.
I have some points to criticize:
- Take your code an run gmoccapy_2_tools_with_cutter_radius_compensation.ngc from nc_files
You will note, that this sample program has an optional stop. After you resume from pause you will note, that the time will not increase any more, as the interpreter did read already the complete code.
- You missed to add the code to set the styling of the panel to be the same as the one gmoccapy uses. It is only an optical aspect, but does not look good. I use Clearlooks as Theme for my gmoccapy.
I changed a litel bit your code, please test with your program where you stopped from pause, IMHO my way it is doing what it should.
(Attention I changed "-" to "_" in the file name to distinguish them)
And we would like to add also a part counter, to indicate 11 parts made
Thank you so much for your support to develop gmoccapy, also for the ones you mentioned in Github, I need to check the code and your proposals as soon as possible.
Norbert
Please Log in or Create an account to join the conversation.
Thanks for you comments.
A good idea to reset the Program Running Counter on start button instead of on stop button.
I found a better way to handle the running state even with optional stop. Just accessing the value of halui.program.is-running instead of the interpreter signal as it fits not so good for this.
- So I eliminated all pins that could also be accessed internally.
- I fixed the calculation of the minutes value.
- And of course I added the Parts Counter. It is currently shown in the settings area. May someone wants to have it at another place, I don't know as I don't need it.
Please Log in or Create an account to join the conversation.