I guess... stupid question

[nullfx]

let me take a second stab at my original question here.

Isn't this a bit of a wheel reinvention for something like the PLC and one of its underlying bus / service technologies like Modbus (being the most common)?

What are the main differentiators between what this brings vs something like OpenPLC which can essentially allow you to create a pluggable back pipeline (the bus) and utilize data in/out from various peripherals that you can program against on your control board (what you might call the brain in this system).

Hopefully this is a bit more concise and less cringey than my last message in conveying the dumb question :P

thanks

[mmoskal]

I think a 12 year old might have some trouble setting up OpenPLC but they should be able to set up a simple jacdac device. The same should carry over to various not quite technical users.

[nullfx]

the question was more theoretical than practical, I've actually never heard of "open plc" before posting this, thinking something like that must exist I googled it to see. when working with PLC's in IoT I've mainly worked with industry standard allen bradly / omron / siemens etc.

Going back to my original question, rather than reinventing what appears to be another modbus type protocol and back-plane bus type system, why not utilize and extend existing infrastructures to do what you're planning / already started doing? What about what you've done is better / different than what already exists? Or is this just doing something different for the sake for doing something different?

I work in IoT and having seen lots of different "always tinker-grade" implementations in the industry and I think it would be great if there were something that would have real world applicability rather than simply another invention for invention sake that has no future outside of children learning how electronics works. Some of us had tinker toy, and erector sets growing up but when we grew up, those went into the bin, and we started working with real world materials applying concepts learned in school which we were familiar with because those toys first peaked our interest.

In today's world I believe it is possible to have both a tool which allows people to learn and build but also build real world production grade things, so I guess my point is / was what's the point of a glorified Snap Circuits IoT edition system that isn't actually built around any real industry based IoT back end technology? Wouldn't it be better to have something built upon what the industry itself is built upon so when the time comes that users move beyond the hello world / blink app and begin to discover what's under the covers and driving the buggy that, people can dig deeper, pivot from a kids programmer model to something they can use at work or for their house or something like that?

[mmoskal]

Jacdac is about enabling anyone to build "hardware" in the same sense as Excel is about enabling anyone to build "programs". Excel is not about teaching people to do "real" programming. Maybe I shouldn't have brought the 12-year-old example...

As for using existing technology, we're really concerned about costs and Jacdac runs on $0.03 Padauks with 64 bytes of RAM. I don't think any other system with comparable level of abstraction does that.

[jamesadevine]

the question was more theoretical than practical, I've actually never heard of "open plc" before posting this, thinking something like that must exist I googled it to see. when working with PLC's in IoT I've mainly worked with industry standard allen bradly / omron / siemens etc.

That's reassuring, because I don't know enough about OpenPLC to provide accurate differentiators 😄

What about what you've done is better / different than what already exists? Or is this just doing something different for the sake for doing something different?

I am certainly not in the business of doing something different for the sake of doing something different. I build things because I believe they are needed, and to my knowledge, do not exist.

There are many different characteristics of Jacdac that we believe are better and different from what already exists. You could perhaps find these characteristics across disparate systems, tools, and protocols, but not in a single technology stack that achieves the implementation efficiency of Jacdac whilst not compromising on usability.

What motivated the creation of Jacdac as opposed to using an existing protocol?

There have many attempts to make connecting electronics easier. Solutions build upon existing technologies, but ultimately, they reach a point where they cannot improve the development and user experience anymore.

Take for example, I2C. Prototyping experiences based on this protocol have seen moderate success. But that success ends when users find they cannot connect more than one of the same device to the bus (address collisions), or when they try to use driver code written for one peripheral to talk to devices with the same functionality, or when their device breaks because a peripheral did not reset correctly.

To address some of these issues, a reasonable next step with I2C might be to add a microcontroller to each module. With a microcontroller in between, you can fix address collisions, standardise peripheral interfaces, but that's where the improvements stop. I2C silicon cannot be modified, the protocol is well established. You cannot hotplug devices, a single device can take down the bus, and peripherals cannot initiate communications. These are all desirable characteristics when prototyping, but cannot be realised due to limitations in the underlying technology. I'm sure this cycle has been repeated across many different protocols in many different domains over the years.

I'm not attempting to bash on I2C specifically, I am eluding to the fact that silicon, use cases, and user base have moved on from the 1980's. Building on the shoulders of giants is obviously the best way to do things, most of the time, but sometimes it is a requirement to reach the shoulders through taking a different path up the body 😁

That's great for prototyping, but what about industrial applications?

Creating a protocol for better prototyping does not preclude its application to industry. We have actively incorporated and made design decisions that allow hardware designs to be flattened and optimised for industrial applications. Reducing the number of interconnections between microcontrollers and peripherals is as advantageous for prototyping as it is for routing traces on a PCB. Hardware abstraction brings unmatched supply chain agility, ever important in the current climate. I'm afraid that's all I can say on this topic.

[jamesadevine]

Looks like someone can't use GH discussions properly ⬆️

[pelikhan]

@nullfx circling back, we now have release the device development kit https://microsoft.github.io/jacdac-docs/ddk/