IIoT Programming in .NET

I’ve been following the Meadow project for the last few years ever since hearing about it on one of Scott Hanselman’s podcasts back in 2018. It is no longer a kickstarter project. In fact, it is a running company and the investors include Miguel de Icaza (creator of Gnome, Mono, and Xamarin) and Scott Hanselman himself. The CEO of WIlderness Labs (the company that runs the Meadow projects) is Thomas Dohmke, the current CEO of GitHub. If they are willing to put their own money and time behind it, I think there’s something there.

Wilderness Labs manages several projects:

Meadow software

The Meadow Project is completely open source and free (as in beer) to use. This is where the magic happens. At the bottom of this post is an example of how one can take a single program and use it on multiple devices, including Windows and Raspberry PIs.

Hardware and Dev Kits

Wilderness Labs developed an AdaFruit Feather Form Factor board that runs .NET (Mono) on a 32 bit microcontroller (32MB flash storage, 32MB RAM, Bluetooth, WiFi) running on the Apache NuttX Real Time Operating System. There is a second form factor that also provides SD card, dual ethernet, and cellular antenna. You can buy the boards individually or purchase prototype kits.

Meadow.cloud

Recently, Wilderness Labs added the Meadow.cloud which allows companies to manage their devices at scale. The cloud can deploy software, perform healthchecks, capture data and logging, and interface to Azure, AWS, and Google Cloud.

To me, the most impressive thing is the Meadow software. It is an abstraction layer between .NET and various hardware/operating systems. Here’s the video I mentioned that shows this in action.

If your shop is already .NET savy and you want to start get into the Industrial IoT space, I think this is a promising path.

4 Likes

I agree - I started watching this about 2 weeks ago for an internal project. Now I just need someone with skills and time that I don’t have :wink:

1 Like

Marvel Cinematic Universe Split GIF by Leroy Patterson

1 Like

Good prototype but it’s much easier to do with Python and standard IR camera interface. Occupational safety is a good use case. Would love to hear how others are using it.

This is a popular response from all of my Python friends who immediately describe prototyping in Python. :wink: Meadow is not just prototyping. It is an entire IoT ecosystem. It abstracts the driver code so it can be written on a Windows desktop then moved to a PI or a microcontroller if power usage is important. It then has a system to manage devices, perform health checks, perform over-the-air updates to devices in the field, and forward data and logs to popular processing services like Azure Event Hub, DataCake, and others with built-in web-hook capability. All of this burden is removed from the programmer because these features come with the ecosystem.

Is it really easier for the Python programmer who would have to write all of this functionality?

:thinking:

And maybe there’s a similar ecosystem for Python. :person_shrugging: But everything I’ve found so far focuses on making it easier for the developer, but not necessarily the goals of the business.

Beauty of Python is simplicity and ability to integrate AI easily. Other end of the spectrum is C++ and more recently - Rust.

C# is not a great choice in my opinion with overhead of managed vs unmanaged while dealing in the Microcontroller realm. If we need more sophistication, ROS is more standardized - not a direct alternative but well understood. Also consider vendor lock in.

While I’m not against using Meadow or similar platforms, your initial idea that its best suited for .NET shops and die-hards makes a lot of sense.

If the objective is to get something simple built or prototyped, Python or MicroPython will be my personal choice.

1 Like

100% agree. I’m not against Python for die-hards either. Python is a very good choice to “get something done” quickly. And yes, some real time applications will require something like Rust/C++ if the data collection needs are stringent. But my focus here is on running a business and not just a device. This is where I see the value in Meadow.

I don’t see the vendor lock-in though. .NET is open source. Meadow is open source. Meadow supports microcontrollers, Raspberry PIs, MacOS, Windows, and Linux. Up until a few years ago, Guido was Python’s “benevolent dictator for life” but they formed the Python Software Foundation very similar to .NET’s foundation. Python also struggled with moving people forward from 2.x to 3.x, but finally the Foundation put its foot down and stopped supporting 2.x. There’s something to be said for having a business that depends on being responsive behind an effort.

I guess I’m back to my Pets vs Cattle point of view. Quickly building a one-off is a making a pet. It is a one of a kind and requires individual care. If something goes wrong, it has to be fixed manually, often by the original creator. But once I scale, say to a dozen or more devices, then simply built solutions often are more difficult to maintain. Let’s say a sensor gets a new feature that would help the business meet some objective. In cattle world, we would update the driver and push out the new image to all devices and monitor them. In the pet world, we would have to retrieve each device and update them one at a time, maybe by the original programmer. Great job security for the coder but ultimately a liability to the business.

2 Likes

Agree with your theme about pets vs cattle analogy but it is not applicable in this context, as it implies that Python applications are fragile, unique, and hard to manage. Python supports multiple paradigms and methodologies that enable developers to write modular, reusable, and testable code. Python also has tools and frameworks that facilitate continuous integration, continuous delivery, and over-the-air updates for IoT devices. Check out this link below.

Python is not only easier to implement, but also easier to learn, read, and debug. It is one of the most popular and widely taught programming languages in the world, which means that there is a large pool of talent and resources available for Python.
While .NET and Meadow are open source, they are still heavily influenced by Microsoft’s vision and direction. Python, on the other hand, is governed by a group of core developers and community members, who decide on the language’s features and roadmap.

For business use case, you need to balance agility with performance. Debates on language features are endless and futile most of the time. It’s best to use whatever tools people can use to make it functional as fast as possible. No matter how great it is built, it will be replaced eventually.

I have to agree with @deepak on this one. I’ve built C# managed microcontrollers and Java/Python (…jython shudders) managed microcontrollers and unfortunately C# though my more familiar language is too slow in most manufacturing scenarios. You could use it for a lot of stuff that doesn’t require speed, but then once you enter <1ms response territory you’re firing up another system.

I’m sure it has a place in a lot of applications, but I would never rely on C# for equipment and safety. It’s the runtime that kills you.

Oh, I’m sorry. I did not mean to imply that at all.

The trouble is not with any particular language. You’ll find hobbyist, DYI-ers, etc. in all languages. I’m strictly speaking from the business-side of the problem. The technical pieces have been in place for a while and Python and C have been at the forefront for most of it.

For most of my time in IT, I have been guilty of building things that just work (in FORTRAN, COBOL, VB, C, LISP, Access/VBA, Java, .NET,…) to quickly solve a single problem. In my advancing age, I look back at the absolute garbage solutions I’ve left behind. < shudder > Sure, it solved a problem at that time but often they blocked better improvements later on because urgency ruled the day.

What has always been missing is the framework to work in. THIS is why I, Scott Hanselman, Miguel de Icaza, etc., like the IDEA of Meadow. Having a library of drivers with the hardware abstracted away is very attractive. To also have a system that maintains the devices and updates them at scale is also a plus. To run the programs on multiple OSs and devices is just icing. Having a well-defined framework would have given me constraints and limited the amount of pure refuse I’ve produced - from a business standpoint.

With Kinetic already in the .NET universe, it makes Meadow friendlier for smaller companies with limited resources. There may very well be something similar in the Python community, and if there is, I will sing its praises too.

Oh, I agree for certain scenarios. Again, I’m thinking at a higher level here. I’m suggesting that this isn’t the either/or argument it’s turned into. From a security viewpoint alone, those safety critical applications should never be directly on the network. However, if you had a PI or Microcontroller gathering the data from those critical systems, then it can upload it to a Data Lake, etc. You are also segmenting critical devices from the rest of the network. As a bonus, you have freed up a C or Python programmer. And, let’s face it: NO hardware programmer is thinking about security. :rofl: TLS takes precious cycles afterall! Why not offboard that communication to something else?

I see a gap that Meadow fulfills. It’s not a panacea by any stretch, but I would like to see more guardrails around all of our programming, not just IoT.

2 Likes

Cetrtainly agree with your idea regarding abstracting hardware for sure and have utmost respect for all the names you have listed including yours. However, do not agree with the choice of using C#. Python is not anyway significantly better but would not have a heart burn if it’s discarded after use.

While we all have regrets about past projects that could have been better, we are all on a path towards continuous learning. We can only hope to do the next project a little better.

Wouldn’t this be equally applicable to Python?

Yes but less so. Python is quite fast especially for calcumalations. Still has a runtime though yes. But at the SCADA level you have to have something digestible. I’d just never use C# as the SCADA driver again. Been there done that, just my own experience, too much overhead.

On an actual microcontroller binary rules the day. Arduino brought great accessibility to that for learning, it’s a fabulous tool. For super non-critical application we run Arduinos as PLCs that communicate with SCADA over ModBusTCP.

1 Like

Interestingly enough, that was a recent Meadow demonstration except over I2C.

Meadow also does SCADA over ModBus TCP if you don’t want to write your own.