Trying to learn to communicate with new device

ASF

Lifetime Supporting Member
Join Date
Jun 2012
Location
Australia
Posts
3,907
Hi all,

Got a new device I'm trying to work out how to communicate with. It came along on Monday morning after 9 months of development inside my wife.

So far I've established that it's quite a temperature-sensitive device, and it alarms quite quickly if outside it's limits.

The primary communication method seems to be similar in some ways to the old PLC's and their audio cassette philosophy, only this one is much, much louder.

While I haven't been able to access the source code (and I think it'd be way over my head even if I could), I am impressed with it's processing capabilities. It seems to use some kind of biologically-based CPU, and has a highly advanced onboard self-learning optical-recognition system. The motion controls look a bit erratic, but from what I understand, they too will self-calibrate over time.

I'm also very impressed with its engineering and design. It's an incredibly well put-together unit, precision engineering like I've never seen before!

In any case, if anyone can give me any tips for communicating with this device, I'll take all the help I can get. I'm losing a lot of sleep trying to make sense of it all at the moment!
 
Congratulations!

On some of these devices you'll never completely figure out the communication protocol. But some seem to develope a simpler version
 
Experience shows that the internal power source is limited with frequent shut down idle periods of varying durations. Spontaneous reboots in the middle of the night are not uncommon, many times in full alarm state. Energy replenishment is clearly one of the alarm conditions.

Industry reports reveal that the multifunction annunciator features increase over time to include various audible sounds.
 
Congrats on your new arrival...(y)

For the time being, I would definitely stick to Explicit Messaging such as guttural noises and/or connected, clinkly, shiny, toy type hardware...:sleep:

Beware of Implicit type 'communications'!...The 'Produced' amount seems to be exponentially greater than the 'Consumed' type one!...:geek:
 
Congrats on the new unit. Sounds a lot like mine. After spending some time with v1.0, I thought I had it all figured out. Then a bit later v2.0 came out. Seems they not only completely redid the OS, some of the hardware was also different. And to this day comms are a completely different protocol. Nevertheless the v1.0 and v2.0 appear to communicate well among each other, even though random collisions keep appearing, both in communication as well as hardware. Both versions came without a manual, so it was all trial and error, still is to this day. Make sure you add enough PAUSE instructions in your own tasks or your OS will crash on power issues. Good luck with yours, enjoy the ride.
 
Thanks for all the tips everyone! Much appreciated! (y)

If you input too much milk
It will output it right back out
Yes, I have observed this a few times - it tends to undergo some minor processing before the output stage.

Experience shows that the internal power source is limited with frequent shut down idle periods of varying durations. Spontaneous reboots in the middle of the night are not uncommon, many times in full alarm state. Energy replenishment is clearly one of the alarm conditions.

Industry reports reveal that the multifunction annunciator features increase over time to include various audible sounds.
Yes, I seem to have been quite lucky in that many of the night time alarm events are non-latching and will silence on their own quite quickly. The ones that do latch I'm still trying to figure out - hopefully that annunciator enhancement you speak of develops quickly!
Congrats on your new arrival...(y)

For the time being, I would definitely stick to Explicit Messaging such as guttural noises and/or connected, clinkly, shiny, toy type hardware...:sleep:

Beware of Implicit type 'communications'!...The 'Produced' amount seems to be exponentially greater than the 'Consumed' type one!...:geek:
There is definitely plenty of produced and consumed data going on, that's for sure!

Get ready to spend a ton on upgrades and hopefully the oem is reputable
Fortunately my wife is extremely reputable. Best there is, in my opinion.
Congrats on the new unit. Sounds a lot like mine. After spending some time with v1.0, I thought I had it all figured out. Then a bit later v2.0 came out. Seems they not only completely redid the OS, some of the hardware was also different. And to this day comms are a completely different protocol. Nevertheless the v1.0 and v2.0 appear to communicate well among each other, even though random collisions keep appearing, both in communication as well as hardware. Both versions came without a manual, so it was all trial and error, still is to this day. Make sure you add enough PAUSE instructions in your own tasks or your OS will crash on power issues. Good luck with yours, enjoy the ride.
Solid advice there! If I obtain a second unit in the future I'll be sure to forget everything I learn with this one ;)

Thanks everyone, I'm pretty stoked with it all 🍻
 
I have a couple of similar units myself, and have found that their communication protocol is almost as buggy as FactoryTalk. Just when you think you understand it, you suddenly find yourself at square one again. I should also warn you that they are a complete nightmare to maintain! The cost grows exponentially as they age, and the ROI seems to keep going down. My newest unit was once a great dishwasher with an out of pocket cost of $5 per week. Now that it is 17 years old... Well, I don't want to scare you :)
All that said, I hope you are as happy with your unit as I am with my two. Operating them has been the worst paying, and most rewarding job I ever had.

Congrats!
Bubba.
 
Enjoy the new parasite while you can. In just a few short years you will be questioning how you are even smart enough to breath! Then comes the real software subscription cost... But finally, the self-replication phase will begin, and it will all have been worth it :)
 
Congratulations. Communication in the early years won't pose as many problems as those encountered in the year 13 -19.
 
Congratulations my friend!...

ASF said:
...Got a new device I'm trying to work out how to communicate with...

Just do what I've always done when in doubt, and fall back on the universal communications interface; the trusty and reliable "WiFe"...

WiFe - Wife to infant Father exchange

It is an invaluable interface to have around when diagnosing a new and unfamiliar Parent/Child device configuration which has been introduced into a Family of products.

I believe that newer WiFi technologies have been based on this timeless communications interfacing method but is nowhere near as versatile and flexible as its predecessor. It has been available since the dawn of time and is excellent at relaying to the Parent device's male aural port what can appear to be garbled data coming out of the Child device's oral port.

Note 1: The Child device will by design inherit certain negative characteristics from the Parent device, which may result in periodic communication issues.

Note 2: After a few years of operation, these Child devices have been known to begin reporting back to the Parent that their received messaging data is garbage, as it has been detected as coming out of the Parent's rear port.

The Parent device may then execute an Explicit Message in an attempt to regain control of the Child device. This has been known to fail, catastrophically, resulting in overheating of both devices and complete communications failure. The WiFe interface will usually intercept these exchanges and force both devices to halt communications for a certain cooling off period. Normal communications may then be once again attempted.

Establishing and maintaining solid communications with Child devices is difficult at the best of times and there are sure to be inevitable incompatibilities between the newer Child device and the older Parent device's protocols and standards. For this reason I would advise keeping the WiFe's "firm"ware up to date to ensure that Parent/Child device communication issues are kept to a minimum. This is usually best acheived by regularly treating the WiFe to off duty relaxation periods.

I would also recommend limiting, for as long as possible, the number of smart interfacing peripherals that the Child device has access to, as this can lead to regular communications buffer overloads, resulting in all Parent device communications being ignored, repeatedly.

I would also highly recommend you subscribe to a good Support Group for advice on Child devices. These are usually best found in your local imbibing rep's establishment.

But above all remember that communications should always be attempted as a 2-way exchange of meaningful data and that whatever the WiFe says, goes.

Regards,
DaddyCool
(2nd Child device's assigned Parent communications identifier)
 

Similar Topics

I am a water treatment plant operator tring to learn as much as I can about programming. We use TSX plcs (Quantum)and program ladder logic using...
Replies
1
Views
1,591
I am very familiar with AB PLC 5 and SLC500, however we have recently added a new system that has a contrologix 5000 in it. Is there any where...
Replies
4
Views
1,804
Hello group, at work we predominately use PLC5's so the only software that I've worked with is logix5. We have a bunch of stand alone Automation...
Replies
11
Views
4,023
I have a S7 416 2DP and I am trying to get it to communicate to a 200. I guess anyone have any links so I can read the setup, I have my 5512...
Replies
10
Views
5,957
Hi everyone. I am trying to learn about PLC5/03's. I have set up an Inspiron 1100 laptop-->usb to serial port adaptor--> SLC 5/03 serial port. I...
Replies
1
Views
2,864
Back
Top Bottom