Motor speed 8 may be too low. My motors generally do not start until around 30 or so. Stick with 50 for now.

Other than that, perhaps take a pic to show your wiring. Maybe someone who has the device can spot an issue.

Wild guess since I do not have any of the pieces, but I suspect changing the motor mode and speed over and over again as fast as possible might have unintended consequences.

Try setting them both, sleep 1 second then set speed to 0; get rid of the while loop.  If that works you need to rethink your logic.

I fought missing mf templates for a day recently. They were there in the proper directories, but never showed up in Visual Studio.

I uninstalled / re-installed 3-4 times, nothing changed.

I think this article finally made things work again; 

http://chiragrdarji....lled-templates/

I'm not 100% sure it was that, but it was some command line argument to devenv. Apparently VS still has some issues finding templates occasionally.

So, My first netduino completely quit talking to the robot.  So I was trying to hook it up to the desktop PC when I had the 12v incident and totally fried it.

But I always did wonder why it behaved differently (and usually worse) than the newer netduino lab board I had (same model).

Then todays story on clone ftdi chips getting bricked intentionally by driver updates - hmmm, things are starting to make more sense. Why it behaved poorly, why it stopped working.

With my luck though the newer will die in a day or 2

So yesterday, I needed to hook up my robot in a new way, including using a USB hub. The only power supply I found near the device that fit was 12V and I thought "what the heck, it has a regulator inside right?"  Wrong, 1 second power light was on, next it was out, for good.

Simple fix, $60 and order another one.

A walkthrough of the User Interface

http://www.spiked3.com/?p=1221

'Simple' is an subjective term. I hook up a saleae logic analyser and I quickly know if it is failing hardware, my code (99.99999%).

So to answer your question, yes very simple way to test it.  The only other way is to take code and a device you know that already works, and try that.

The third way is to find someone who has either of the first 2 ways.

If none of these are available to you, then no, there is no simple way.

I always thought it was kind of a cool idea, but never had a reason to use it;

https://www.sparkfun.com/news/1527

Assuming you have internet connectivity, since you mentioned Azure, I suspect you do.

I use MQTT, which probably makes more sense, but not as much fun since I already know it

https://m2mqtt.codeplex.com/

I have heard it is a known bug in MF. So maybe fixed next MF release. It is probably related to why they are redoing the TCP stack, among other things.

You are confusing 'fast' with 'apparently fast because it does nothing for you'.  I agree sometimes appearance is important, but it's not the chip. The Netduino chip runs circles around anything on an Arduino; at very least its 32 bit vs 8.

I've said it before and I'll reiterate; the Netduino targets developers who are familiar with the .Net environment, or who would prefer to learn with a .Net environment and there are plenty of reasons to. .Net/C# being a modern managed object oriented platform is top on the list.

Indeed there are times when raw speed is more important, and times when it is not, and a lot of time in the middle where it is just a matter of knowing how to achieve apparent speed. Sometimes figuring out how to make the Netduino look fast is the enjoyable challenge we are looking for.

I have a particular example; I wanted something that could read quadrature encoders from 2 motors, control both of their speeds and incorporate 2 ultrasonic sensors to prevent running into things. It connects to the main computer and receives 'commands' via ethernet. The commands I send it are high level;  'move 14.3 meters' 'turn 43.2 degrees right' 'move 17 meters in reverse' all the while telling me exactly where you are 15 times per second.  Can an Arduino do this? Probably, if I started now, in about 18 years ( I have no embedded development experience, no hardware experience, 25+ years Application software experience with C#). While I have cussed it several times, I expect I can accomplish it on the Netduino considerably faster (Actually it is about 90% complete, in a couple of months). Believe me, if I could buy an off the shelf device that did this (like a LEGO could 10 years ago) I'd be happier. But I can't, so this is my fastest way to something I want to move my Robot, without hacking hardware and learning a new profession in depth.

I do not follow your comment about interrupts. My application uses 6, the Arduino has 2. I would have to stack 3 Arduinos, plus probably a 4th with an ethernet shield, to get the same capabilities. These are real interrupts, they can not be missed 'whenever' like software versions do. Want a good example? Try using a software serial port while you are doing other things with your Arduino.

http://www.spiked3.com

Perfect, thanks for that. I have a feel for the grey line between hardware and software having worked some with the microcode interpreter that makes an IBM system 370 run (the good old days). I'm sure that idea has carried forward, but I am not intimately familiar with it anymore, like I was.

Great explanation on why on the single interrupt handler. My code currently wraps threads in objects, so I sort of accomplish the same goal (re-entrant single code instance), albeit a slightly different path to get there (the encoder stuff).

I didn't know that CW2. Somewhere I read the timing could be off by 4us, so I kind of guessed at the rest.  I guess it also depends on what you consider low level code, as pin logic certainly could be considered really low level code, but you're right it was not what I was thinking.

Is there any reason to re-use an event handler other than to save memory, and we are talking about a very tiny routine as discussed.

You are pretty close to that now. The wait function you posted, is close. But instead of (reading and) setting wait_Flag in this routine, set it in an interrupt routine as described in my last post.

Yes, you can make a nice little class out of it, but you'll have to make arrangements for multiple wait flags, one for each pin/switch maybe. You will have to do a little exploring on your own, you learn so much more that way.

If you do get stuck, follow up with questions. BTW, looking at your code, you are doing fine for a newb

Hopefully, you have some UI experiences with message pump applications, like windows.  Think mouse buttons. You get an event mouse down, a different event for mouse move, and yet another for mouse up.  

You can tie any digital pin as an interrupt with the netduino (to my knowledge) as its not really an interrupt but a flag to the low level code to poll the pin and post an event at level change, and this appears to your code as an interrupt event and the actual event is time stamped with the actual poll time, so while your code may not get it exactly when it happens, you do get a good timestamp of when it happened. At least this is my understanding, and so far has worked out.

With that in mind you do the same, post as a mouse/button down event up a level, and in your code check to see if that event occurred. Dont forget to indicate that the event has been 'handled' if appropriate, and dont forget to take the proper action, for mouse/button down and mouse/button up.

Quick look at your above code; make Wake_SW global. in a level high interrupt, set it to true. When you handle it in code do not forget to reset it to false. Also if you are not doing both level down and up, you need to re-enable the interrupt each time it occurs.

If I have any of this wrong, please someone jump in, but I think this is the way it works.  I'm using 2 motors, 2 interrupt pins per motor (ie 4 interrupts) and I think it is doing ok reading encoders (now, after a lot of experiments). I get some jitter determining speed, but I think that is just frequencies not being perfectly aligned (motor encoders vs firmare polling), so I smooth them out. At least until somebody explains otherwise to me. To my knowledge, I am not losing any interrupts, just getting the velocity jitter, when the motion is smooth.

I'm lazy, I hate typing more than I have to. As a result, I have adapted a method that avoids having to add 'static' to every function and variable, and follows the Arduino model a little closer. I insert the following code in just about every project I start.

I hope this prevents some carpel tunnel syndrome for someone;

namespace Junk2
{
    public class Program
    {
        bool instanceDone = false;
        DateTime lastTick;
        EncodedMotor M0;

        public static void Main()
        {
            var p = new Program();
            p.Setup();
            while (!p.instanceDone)
                p.Loop();
        }

        void Setup()
        {
            // do initialize things here

            // pwm, phA, phB, reversed
            M0 = new EncodedMotor(PWMChannels.PWM_PIN_D5, Pins.GPIO_PIN_D9, Pins.GPIO_PIN_D10, true);
 
            lastTick = DateTime.Now;
        }

        void Loop()
        {
            DateTime thisTick = DateTime.Now;
            TimeSpan dt = thisTick - lastTick;

            //.... more stuff

            Thread.Sleep(1000 / 20); // update N times per sec
            lastTick = thisTick;
        }
    }
}

Lock requires any object as a reference only. So you can use any reference variable that both places that need to lock have access to.  It is often easy just to create something for this purpose then in both place surround your code with; lock(lockObject) { ... }

Make sure you do it at a logical place, like before a transaction starts, but not too early or for too long.

namespace junk
{
    public class Program
    {
        static Object lockObject = new Object();
        public static void Main()
        {
            new Thread(thread1).Start();
            new Thread(thread1).Start();
            new Thread(thread1).Start();
        }

        static void thread1()
        {
            lock (lockObject)
            {
                // ... do stuff
            }
        }
    }
}

One thing that caught my eye was calling request.dispose, after using it with a using statement - i'm not sure of the consequences of a double dispose.

 The Netduino is as stable as a rock and compared to the Intel, light years ahead. ...

What is your experiences that reveal that? Unless it is that it has been 4 years without enhancements and bug fixes, I get that.

I've only played with the IoT a minute, but the debugging on it was rock solid, as opposed to a random number of reboots on the netduino every time I hit run.

As far as non-debug running, the IoT is months old, versus years for the Netduino (and MF) family. Not quite a fair comparison.

It was given thought, and that scenario was not included. Netduino targets .Net developers. You aren't one of those? It was not intended for you, move along.

Although it is not very hard for a beginner to pick up one of the best of all time languages with a zillion samples on the internet. Some are just too smart for that.

Thinking you can just add .Net support into an IDE designed for non .Net is exposing how little you really understand the technology. I suggest he integrates JAVA first.

yeah, linux is taking over the desktop too, haven't you heard?

how do you code that in C#?

Heh, I've been avoiding hardware as long as I can, but I know it's coming ....

Got a handful of attinys this week, now if I can just find a USB plug that fits...

If shipping to the US is included, put me down for 50. I'll hand them out at robot meetups

Oh wait thats just the chip, n/m.

Lousy toolchain? What is your criteria? That it must look archaic? That must be it if you are thinking uecide is in the ballpark.

Sure there are a lot more imbedded level code samples/examples for the Arduino. It has a large community with that as the focus. The Netduino community is rather small and young so far. But there is no comparison between the languages Wiring (C++ like) and C# or even VB.Net. .Net is decades ahead of Wiring language wise.

An then are NO high level functions provided by an Arduino.  The code you write is all that is running, tiny, simple and mostly fast.

.Net provides much greater functionality. No need to use pointers (yes, they are a bad thing), Actual remote debugging, (not printf to a serial port), collections similar to STL (which I have never seen on an Arduino), actual documentation (up to date and not some stale automatically generated help files) .... and many more I can't think of at the moment.  These are provided at a cost of speed, but they are usually are written in a manner that is far more efficient than anything you are going to write that does the same thing.

And now let's talk IDE.  The absolute worst case is Visual Studio may not be the best anymore, only tied as the best (Eclipse). And in a .Net environment, you can not even say that, since Eclipse does not do .Net debugging. Refactoring built in (change a variable name one place, the IDE takes care of it everywhere, automatically)  Find definitions and references to variables, not some limited text search and replace, that does not consider the language syntax. Project management without the need to manually edit and manipulate build/make files, although that is an option if desired. And my favorite, it does not look like it was written by dinosaurs in COBOL.  Having a professionally thought out IDE is especially important when you spend 8+ hours a day writing code. Visual Studio has been maturing for 25+ years, from a company that knows a little about how people use computers (like it or not, still 87% market share, down from 95%). 

Pete,

What I was refering to was this blog posts; http://blogs.msdn.co...6/27/hello.aspx

The post clearly states "in the next few weeks", and was posted in June. I'm sure that was true from the bloggers perspective, but given a lack of anything else, it is also what I made decisions with.

I think many here have expressed the frustration with being left to believe something is coming soon, then hear nothing more about it for a year or more.

Best of luck to you, I truly hope for your success, I have a lot invested in it at the moment. I'm really hoping that was not a bad decision. 

Putting a Netduino into production and calling wall warts cheap china crap is pretty much an as far from a success story as you can get. Good luck. Where do you think all the parts on your Netduino are made?