Argon has two programmable front panel LEDs that indicate the state of drive. Having just 2 LEDs is challenging as there are more than dozen different states that need to be distinguishable. The current solution looks like this.
The present way is to assign orange led solely for faults and green led for motor control sate. To fit large number of states in reasonably short and easy to read blinking sequences, we’re blinking them by combinations of short and long flashes. One state for example can be repeating pattern of short-short-long-pause and another long-long-short-short-pause.
LED blinking example. The sequence here is long-short-short-pause.
The Wiki page (link above) has animated images from each combination making them hopefully easier to identify. What do you think about this approach (please leave a comment)? Another alternative I have been pondering is just flashing led certain number of times. Such as one state is 3 flashes, another 4 flashes. The problem is counting reliably something like 15 flashes.
Meanwhile in production: the first release candidate Argon batch should arrive any time now! Last week factory reported mistake of getting wrong type of bridge rectifiers which caused 2-3 days delay to planned schedule but drives should definitely arrive this week for final testing.
I like the scheme as illustrated, orange for faults only and green for motor states. I think that a pattern of flashes is much preferable to counting flashes, I feel counting flashes takes too long. Looking up the code pattern in a table may initially take a little longer vs counting, but with familiarity it’ll be much faster, especially for those implementing multiple drives over different installations.
Regards,
Jason
Hi Tero
To identify the various errors with a single LED
I propose the following solution
Each error is assigned to a 2-digit number
Error> 11 = general fault
Error> 12 = default encoder
Error> 32 = default engine link
Numbers are represented by the LED in two sequences
for 11
blink pause blink
for 12
blink pause blink blink
for 32
blink blink blink pause blink blink
etc …
blink = 0.5s
Pause = 2s
You can also turn on the LED for 2 seconds between two error codes to distinguish them
Hmm, I guess in this method you’ll need 2 pauses: one between binks and one (longer one) before the sequence is repeated. Worth considering.
One quite similar idea I like is:
b=1
bb=2
bbb=3
bbbb=4
bbbbb=5
B=6
Bb=7
Bbb=8
etc
Where B=long blink b=short blink
Good idea to reduce the number of counts
This also avoids mixing short and long which could create confusion
But be careful not to make too quick short flashes, which would be more difficult to counted in industrial or inaccessible environments.
I like your two digit method, plus long pause as describe below, because It‘s simple no need learn other combination.
(21 encoder problem) bb pause b
(also 32 under voltage) bbb pause bb
(also 53 unknown) bbbbb pause bbb
or similar to…
(21 encoder problem) bb pause b
(also 32 under voltage) bbb pause bb
(also 53 unknown) bbbbb pause bbb
Sorry the message didn’t show up, preserve character has blocked some contents, here try again
{long fast blink = please prepare to count and jot down }
(21 encoder problem) bb pause b { long pause }
(also 32 under voltage) bbb pause bb { long pause }
(also 53 unknown) bbbbb pause ppp {loop back to fast blink again}
Or
{latch LED 5 secs = please prepare to count and jot down }
(21 encoder problem) bb pause b { long pause }
(also 32 under voltage) bbb pause bb { long pause }
(also 53 unknown) bbbbb pause ppp { long pause }{ latch LED 5 secs again}
Here what I meant, sorry to mess it up ;-)
{latch LED 5 secs = please prepare to count and jot down }
(21 encoder problem) bb pause b { long pause for jot down }
(also 32 under voltage) bbb pause bb { long pause for jot down }
(also 53 unknown) bbbbb pause ppp { long pause for jot down }{ latch LED 5 secs again}
Sounds very understandable! I will give time for the ideas in my mind and try them some day.
BTW, LED blinking is done in open source firmware, so anyone will be able to experiment/improve the indicators.
There was any special reason not to use 2 digits ?
Much better, and it would not get the drive much more expensive.
Counting leds blinking to solve a problem while under stressing working conditions (for example working in a client installation) will result in wrong counts. Also a client to diagnostic a fault will be hard.
For me a bad idea.
Yes, digit display would be preferrable but there are reasons why we chose leds:
1. No empty space left for digit display at least without stacking second PCB inside. Didn’t want to make drive 20 mm bigger to fit the digits.
2. No enough free I/O on MCU to control them. Would need larger MCU just for digits.
3. In 95% cases user can connect drive to PC and view detailed status from Granity software if error reason is unclear.
Good discussion. The clearest way is to have only few combinations.
For example:
Green ON Orange OFF – drive OK but not enabled.
Green blinking Orange OFF – drive OK and enabled.
Green OFF Orange ON – drive fault – torque off, the drive couldn’t operate w/o the operator done something (error reset, power on reset etc.).
Green OFF Orange blinking – drive warning – there is a problem, but the drive still can operate w/o operator’s influence (temperature warning etc.).
The further diagnostic should be made by a special tool – it could be the Granity SW, a third party operation panel or a dedicated GD operation panel which is optional to the Argon – one system integrator needs only one dedicated panel. If the end customer wants to invest in such an operation panel – it’s also OK. From the marketing point of view it’s the better solution. It’s more useful for the end customer too. Lot of the industrial drive suppliers make it like this since decades.