![B)](http://forums.netduino.com/public/style_emoticons/default/cool.png)
![Photo](http://www.gravatar.com/avatar/f91c120bf57efdd61b5efef671acd9ef?s=100&d=http%3A%2F%2Fforums.netduino.com%2Fpublic%2Fstyle_images%2Fmaster%2Fprofile%2Fdefault_large.png)
Netduino - Industrial/Commerical Applications
#1
Posted 17 April 2012 - 10:39 AM
![B)](http://forums.netduino.com/public/style_emoticons/default/cool.png)
#2
Posted 17 April 2012 - 06:33 PM
![:)](http://forums.netduino.com/public/style_emoticons/default/smile.png)
#3
Posted 17 April 2012 - 08:51 PM
Hi James,
impulses with a frequency of about 100Hz can most possibly be handled by Netduino. But you can't say exactly when each impulse occured. Each impulse has a time stamp but this stamp is a few micro seconds of because the .NET Framework isn't realtime.
Of course first you should build a prototype before ordering 1000units.
Regards
Guido
Thanks Guido - The timing of the pulse and when it occurred isn't really something I require - I know if I want to calculate speed/frequency I'll have to try and test a stopwatch class and see if it's accurate, if not I can just get a real time clock chip that should suffice (I hope!
![:blink:](http://forums.netduino.com/public/style_emoticons/default/blink.png)
The main issue I believe is just counting the number of pulses, assuming that we don't miss any pulses on a Netduino? (Does this happen ever, if say the board is very busy may the .NET GC kick in and remove stuff from the Interrupt queues?
Is 100hz capabable with .NET interrupts, or would I need to stick some C/C++ Interop in there? Does anyone have any tutorials/links on Micro framework interop??
![:rolleyes:](http://forums.netduino.com/public/style_emoticons/default/rolleyes.gif)
#4
Posted 18 April 2012 - 08:00 AM
sadly I've to pass your question on to someone else...
...assuming that we don't miss any pulses on a Netduino? (Does this happen ever, if say the board is very busy may the .NET GC kick in and remove stuff from the Interrupt queues?
But I'm very interested how the questions will be answerd.Does anyone have any tutorials/links on Micro framework interop??
Guido
#5
Posted 18 April 2012 - 11:51 AM
If the target of the project is near to a "mission critical", or it's important not losing any pulse, I wouldn't rely on the Netduino itself. That especially if there are "noisy" devices or wiring passing close to the board.
Hardware.
If I were asking for a very reliable "box", I'd pick my Netduino, and I'd enclose it in a metallic (i.e. shielded) box. I also would take care about the supply, and the good grounding. Any wire coming out or getting into the box, should have to be well checked, and maybe shielded. All that assuming the wiring (supply included) aren't too long (let's say below one meter). I wouldn't reject an opto-coupling whereas better than avoiding it.
Upon these conditions, the "box" could be considered pretty reliable from the hardware/noisy viewpoint.
Software.
Netduino (as well as the MF) isn't a bullet-proof framework/firmware, and I wouldn't rely on the service 365 days a year. Nor I bet on a prototype not losing any pulse for a whole day. The system is garbage collected, and it's pretty hard to know what's in the pot will boil.
Instead, I'd use an inexpensive hardware counter, such as many RTCs, which have also several advantages:
- an RTC, which can be always useful;
- the counter (only) can be bat/cap-backupped, thus yields a real non-interrupted servicing;
- it's decoupled from the main board, so any soft/hard failure won't lose the ability to count the incoming pulses;
- I'd bet 1000 Euros on a small stupid chip, over a 1 cent on a very complex machine (imagine a health-critical circuit);
- no need to hack the firmware. Also easier to design, 'cos there's no pain.
Hope it helps.
Cheers
PS: if anyone is asking for thousands of boards, just PM me.
#6
Posted 18 April 2012 - 03:15 PM
Mario addresses a very important point with the "noise" issue.
I've designed a DCF77 remote controlled clock. Everything was fine until all my devices were connected together. After that my clock received an additional clock impulse from one of the other components every 10 seconds.
I resolved the problem by throwing the remote controlled clock away. A RTC was implemented instead.
My point: Mario is right in all of his points and I myself have made my share of bad experiences in counting/measuring pulses.
Guido
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users