Subject:
Re: [gnupic] about data tables and shared variables
From:
Lope Vega ####@####.####
Date:
30 Aug 2008 20:45:03 -0000
Message-Id: <782551.78638.qm@web28203.mail.ukl.yahoo.com>
Thanks a lot for those quick and wise replies guys,
Well, my goal is to have four switches in total, as follows:
* one as the counter (which increments it each valid pulse).
* for the last three: one adds, other substracts, and the last enters/exit editing mode. These would add and substract from let's say a variable called `target' which would always be the number the counter should count up to.
What I'd love to do is to have the display running as normal (not difficult on it's own), but when the enter/exit button is pressed, the displays' refreshing rate would become slower, thus, blinking while showing the value of `target' to be (or not) modified.
Then, one could set new value and press the enter/exit button (or also let it take effect through a timeout), which would since then take effect.
That way, which makes everything twice as complex, I shouldn't need to hardcode the `target' value on the pic. While it will usually be 100, on rare ocassions I might need it to be 90.
Once `target' has been reached, a stepper motor to move 90 degrees forward, wait till another valid pulse has been seen, and then return it to it's initial position.
This is for a machine up in my family's factory where I'm trying to get rid of a pneumatic piston/electro-valve system driven by an omrom digital counter, which, perhaps because of vibrations, uses to get rendered unusable quite often, and they are quite expensive (about 300 euros).
Appart from that, the fact of being based on pneumatic with no apparent reason (both the torque needed and the length of the automatism is very little), implies having an air-compressor being turned on all the time. In this case, that air-compressor consumes about twice than the machine itself, so I'm seeing it as not worthy at all as the times goes by.
So I guess what you suggested is the right way to go. I just setup interrupts for the buttons, and when one is seen, I could discard if not applicable (i.e: the `add' button was pressed but the device hasn't fallen into `editing mode' [the enter/exit button wasn't pressed]), etc.
Once I get more experience, I'd also like to see the variable `counter' being updated in rom (after each valid pulse), though I guess I should use an external eeprom so I'm not killing the pic (due to the "limited" number of times one can write to it). That way I should just need to desolder the external eeprom, and replace it by a new one when it gets exhausted. Also, the `target' variable would be saved.
That would be a great advantage because by turning the machine on, it could remember not only the last `target' assigned, but the last count it got, so it can continue from there without any need of human intervention, which could even result in erratic behavior if forgotten (i.e: the default target is `100' but today we were producing at 90 units/bag and the labourer forgot to set it up).
By now I'll more than happy if being able to letting it work the simplest of the ways. If I do the pcb properly, I can always take the chipset out and upgrade the firmware at home as I get experienced and implement those things I'd like to do.
Anyway, thanks a lot for the comments, I'll continue with this and try to get help or advise from you if I get stuck, which I expect to happen unfortunately.
Many Thanks,
--- El sáb, 30/8/08, Peter Stuge ####@####.#### escribió:
> De: Peter Stuge ####@####.####
> Asunto: Re: [gnupic] about data tables and shared variables
> Para: ####@####.####
> Fecha: sábado, 30 agosto, 2008 7:22
> Lope Vega wrote:
> > My question is about how to handle it.
>
> A matter of taste really.
>
> I suggest having main scanning over the LEDs and to have an
> interrupt-on-change for the switch input. When the switch
> interrupt
> fires, start timer 0. If another switch interrupt fires
> then restart
> timer 0. When the timer 0 interrupt fires the input has
> been
> debounced so update the values that main displays on the
> LEDs.
>
> This does not scale for many inputs but if you only want
> one input
> it's a simple solution. You can of course add a little
> multiplexing
> code to allow handling more inputs.
>
>
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail:
> ####@####.####
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
