This is so cool, who says you can’t teach old automation new tricks!
Ok, I need some input on how you guys would like this board laid out. Here is a PCB that will fit into the Polycase enclosure that I listed, and will allow you to plug P3V3 into it. The components aren’t laid out yet, I just want to get an idea of what connectors to use. I think that the 2.1mm barrel connector makes sense for power, but I will use a through hole part instead of SMD and then you can populate it or not. I could just place a row of 0.1" headers and not use an RJ45 connector at all. Then you can either install screw terminal, solder to the board or mount an XLR connector. Thoughts?
Then you can either install screw terminal, solder to the board or mount an XLR connector. Thoughts?
Seems good to me as you got both the lighting & industrial needs covered best get BA’s comments on XLR as he’s the lighting specialist.
I think this is a great idea.
Anybody have an example device they want to talk RS485 to? The kaylee code has been in need of a refresh for some time and I’d like the new base code and examples to actually be helpful. Extra points if you can suggest something I can easily get my hands on to write code against.
I’d like to hear about this as well. I (MakeDeck) have Kaylee in stock and nothing to connect it too.
I’ve just received a couple of kaylee’s from MakeDeck and will be hooking them up to a rs485 demo system.
The first protocol I will be running is simplex 9600,n,1 is made of eight 8-bit bytes, they are 7 payload and the last a Negative 8 bit 2’s complement checksum of the sum of the first seven (I am not looking forward to the checksum bit)
The other protocol I would like to try of course is DMX but I’ll have to go and buy something off ebay for that, the issue with that is the imp cannot produce the correct timing for the break a the moment (that said, a lot of devices might be forgiving of that)
If you could make imp code that would do properly timed dmx that would be the one to do, as imp+dmx+ebay=fun 
and would be great for the holiday season.
@back_ache single pin dmx is in the release queue; we have a disco light displaying build status in the Cambridge office
Wow, US to UK in 7 days through First Class Mail, that might be a record. Give us some inexpensive examples if you see any.
@philmy That’s great to hear, I have the feeling DMX could be very popular, what would be nice would be to set out some standard way to work with it so that different hardware and software solutions were interchangeable (like we see with people RGB led projects).
For example I would like to see if we could keep dmx outputting imp’s in sync (by using unixtime as a UUID on a queuestack for example)
When is the release due and has the timing been checked with a scope as @physicsnole did before?
It’s not yet a native api for dmx; you’ll still need to reconfigure a pin between digital out and uart tx, but you’ll be able to specify the initial digital out state and there should be no glitches, e.g:
hardware.pin5.configure(DIGITAL_OUT, 0); // new second parameter is initial state imp.sleep(0.0001); // might need tuning hardware.uart57.configure(250000, 8, PARITY_NONE, 2, NO_CTSRTS | NO_RX); hardware.uart57.write(outBlob);
I’ll let @hugo respond about the release date. It won’t include anything for dmx syncing though.
the syncing I was thinking about at a higher level another example would be a timed fade.
Perhaps to “tune” the break you could reach out to @physicsnole who spotted the issue with his scope.
@tbyrne I’d love to see Electric Imp’s take on implementing Modbus RTU over RS-485.
It would be fantastic to have an agent which uses Rocky and has an API for configuring baud rates, parity, stop bits, etc. and also allows you to dynamically (or very easily by changing the code at least) load different register maps (register address, register count, register data type, scaling factor, etc.) and change the polling algorithms, logic to perform based on certain registers and the type of connected device, etc. Big bonus points of you also tackle a nice UI (Bootstrap + some dashboard type widgets?) and User Authentication / permission levels…
One thing that would make this much easier is for Electric Imp to extend the blob class to include more functionality. Having implemented Modbus on the imp (and several other platforms) dealing with things like swapping register endianess and word endianess (which may be inconsistent even with registers on a single device!), and converting 8, 16, 32, and 64 bit signed / unsigned ints, floats, chars/strings, custom format timestamps, binary data, etc. is always fun. Adding some more functionality to the Blob class similar to Node.js’s Buffer class would lower the bar for many developers.
I have a working Modbus implementation (it skips a few checks like silent periods and the like - but in practice that sort of thing rarely matters) that I’d like to contribute but since it was made on company time it’s not my decision to open source… I could however offer my advice along the way and contribute to any new work on my own time.
There’s not much that speaks Modbus that’s particularly cheap but none of it is hard to get ahold of either - something like a Shark Electric Meter can be found on Ebay
We have a modbus class under construction right now - will be open and posted when we’ve had a chance to test it a bit more with real hardware
@deldrid1 a node buffer class is a great idea and would allow porting from node modules etc. So +1 for that.
@deldrid1 The only real difference between most of those Node Buffer methods and the corresponding Squirrel blob APIs, is that the Node ones all take an offset and the blob ones read or write from the stream pointer:
x = buf.readInt32BE(n) --> blob.seek(n); x = swap4(blob.readn('i')
the float ones need a bit more verbiage:
x = buf.readFloatBE(n) --> blob.seek(n); x = casti2f(swap4(blob.readn('i')))
though there’s admittedly no real way of reading or writing big-endian doubles. And blob.slice() would indeed be a useful addition.
Peter
@Hugo do you have an ETA on the Modbus RTU class? I’m sizing up whether to bash out my own implementation or wait for EI’s solution. BTW, just started working with imps - simply fantastic!
Very soon, as it seems to work well in our testing. Gino, you reading this?
I’m aiming to push a simple modbus implementation to our repo sometime today.
@deldrid1, it’s a bit more barebones than what you’ve described, but I’ll definitely take your suggestions into account. And if anyone else has feature requests or bug reports, please let me know / submit an issue on GitHub. Thanks!