Sign in to follow this  
Followers 0
Mr Jinx

home automation and a SLC500

13 posts in this topic

Hi, I am building a new home and am installing an SLC500 to control all of its features other than AV which I am going to use AMX NI3100. What I would like to do is set data in the SLC via rs232 communications, so rightly or wrongly I have set up a 5/04 processor with a 1746-BAS unit in the next slot with a view of streaming rs232 text strings to it and then using a basic program to interrogate the string and set the data tables accordingly- so far so good I hope? This is where I come unstuck as I have not programmed PLC’s for many years, the last being PLC5 nor have I programmed a 1746 – BAS module. So if there is anybody out there that could help me on the following subjects I would be made up:- • Programming the bas unit, what software do in need and what cables – I think it can be done with hyper terminal? • Sample program that pulls the text data from PRT2 port and how to use the BAS to write into the data table. • The reverse of above to read from the data tables and then send a text message out on PRT2 to the AMX unit. If the above is all rubbish and there is a better way of doing it please shout I am not proud, however I am on a personal budget and it is running out fast so cheap is good hence why I am using SLDC500 thank you eBay. The AMX NI3100 can use either rs232 or 485 if that helps?

Share this post


Link to post
Share on other sites
My first question is why the basic method? What is going to be sending the data? If we know the data source, there might be a better method.

Share this post


Link to post
Share on other sites
I am using second hand equipment to keep the costs down so have been pushed by availability and very little knoledge. The equipment that I need to talk with is an AMX NI 3100 which in essence is a black box pc which can be programmed and sends either IR RS232 RS485 or IP commands out. I will be talking to that unit via an Ipad and then that needs to tell the SLC500 what to do and visa versa. So if there is a better way please share

Share this post


Link to post
Share on other sites
The unit is at the below address:- NI 3100

Share this post


Link to post
Share on other sites
If you are paying more than $500 for the PLC for instance, you can buy NEW Micrologix stuff cheaper than that. I'd only consider using the SLC if it is free. PLC Center should give you some good idea of what used stuff is priced at. If anything ever breaks, anything in the SLC line is going to be very expensive to replace. If you are using a Micrologix 1100 or 1400, it has a built-in web page. You might also want to look at the Red Lion G30x displays. Very inexpensive and has built in web capability (with decent graphics). The simplest alternative based on what you described is using the ASCII commands on the SLC and sort of making your own protocol.

Share this post


Link to post
Share on other sites
Hi I am getting the stuff very cheap however I did not know about the micro logic. Ido have all my hardware so looking at the best way to use what I have

Share this post


Link to post
Share on other sites
You may want to look at Ignition from Inductive Automation. It already supports the PLC you have. The single user version license is free. Otherwise as I said, have fun with the ASCII protocols and the serial port. Ipad by the way is very annoying. If it isn't sold as an app, there's no support. No flash, no Java, some vague HTML 5 support, etc. In this respect, Apple is worse than Microsoft...if it isn't in their sphere of influence/control, it doesn't work.

Share this post


Link to post
Share on other sites
that looks good thank you. The point of using the bas in my mind was to pass control instrutions from the PLC to NI 3100 and visa versa as I want to have all my Audio Visual and building seaml;esly working together. I will look at the ascii control functions as I have never used them before - I just thought it would be easier to do in basic

Share this post


Link to post
Share on other sites
First off again, you can use Ignition from Inductive Automation. It's free. No protocol writing needed. There is also C++ code and Java code floating around on the internet that implements both DF1 and PCCC which allows you to use the native protocol built into your PLC without writing any ASCII code on the PLC at all, and no protocol code on either side. This places you way ahead of the game in terms of getting things done. You need only to develop your screens and work out how to get them to show up on the Ipad. Working with an Ipad is somewhat difficult in that it's a closed architecture...you will need some kind of App to talk to the PC side because Ipad doesn't support Flash or Java. I suppose you could remote connect via VNC or some such and do screen scraping. Low end technology but at least it works. I strongly suggest going that way. Writing protocols and protocol handlers is a nontrivial affair. I've been doing them off and on again when absolutely necessary over the last 20 years, and I consider myself pretty good at it. I wrote some of the code in some of the KA9Q TCP libraries in the 1980's as well as the first available Usenet/Citadel BBS gateway back when the "standard" PC was 8086 and DOS based. In spite of having lots of experience doing it, I'm recommending not doing it. It looks easy to write protocol handlers but it's not. You've basically got to approach the whole problem as if anything that can go wrong in the communication stream probably will. So 75%+ of your code is simply cross checks and validation. The code turns into pure spaghetti logic if you don't approach this in layers with data encapsulation, each layer doing one piece of the total package. You will run into all sorts of kludges in your code if you don't follow a strict layer methodology, which is tough to do because many times how you build your layers is touchy. For instance let's say that you have an "escape sequence" to protect "special" start/stop characters, which is common, and you have a start/stop character to delineate a packet. If you make the inner loop handle the escape translation logic, it could "eat" a start/stop signal if the escape gets triggered inadvertently. So then you protect it with a timeout. But this timeout can conflict with the next outer loop which looks for the start/stop signals. So ultimately the easiest way is to push escape translation way down to the command interpretation level but then you have escape translation redundantly in almost every command that takes a parameter. See...it gets very messy, very quickly. Many protocols get screwed up in the design process, even with experts. Hence the reason we are on IPv4 (or V6...notice V5 never came into existence), and IGMP version 1, 2, or 3 (all incompatible). Those are major internet protocols and even the experts took several times to get it right. The BSD TCP/IP protocol stack which in itself is actually quite simple and is the "library" behind virtually all major operating systems (Mac, Linux, and Windows all use it, although Microsoft took pains to make it look like Winsock is anything but BSD 4.2 or 4.3 or probably 4.4 now) is currently at version 4.4 last I heard, so obviously it took several times to get even something as important as that right. If you want to do it yourself, I'd recommend getting a copy of the code I mentioned above. It takes a little searching because it used to be free and now they are charging for it, but the code in C++ is called "ABEL" and was written by Ron Gage who has now moved on apparently to be a wedding photographer. Even if you are not well versed in C++, it is written cleanly enough to be readable. Ron sold the code to someone else, but the original (free) versions are still floating around on the internet. This assumes that you write code in the PC side that uses the PLC's native CSP/PCCC Ethernet protocol. The DF1 protocol is nearly identical in many ways. AB gives away free documentation in their tech library on the code. The DF1 side is accurately documented and works well. The Ethernet version is basically totally undocumented but between Ron Gage's code and Lynn Linse's web site you can piece together the differences. You may also want to look at Lynn Linse's IA protocol tips as he gives away a lot of details, too. www.iatip.blogspot. Lynn is pretty good at writing protocol translators. At least 2 of the Digi One gateway devices are his handiwork. Reason I suggest going this route is that then all the programming on the PLC side of things is already "done" by Allen Bradley. You only have to implement one side (the PC side). DF1 and CSP/PCCC are about as simple as it gets. There are some features that you won't use but it's not enough to matter. An alternative is that you can use Modbus. The modbus web site (www.modbus.org) has all the documentation for free (truly free, not just sort of free unlike ODVA or OPC). The protocol is unbelievably simple and again, someone else worked out most of the details for you already. There is source code for modbus all over the place and it's so simple to do that you can write your own in a few hours if you are experienced with this sort of thing. If you go this route, and you have access to RS-Logix 5000, Allen Bradley has free code for Modbus for Logix-based processors on their web site in the sample code archives. Modbus is popular partly because it is just about the simplest protocol out there, even the Ethernet version. In contrast, Ethernet/IP looks like it came from a foreign planet. Only about 10% of it's features ever get implemented. You can write your own protocols, too. I'd recommend taking hints from above. You might be able to simplify in some cases but not enough to matter. I've done this with industrial ink jet printers from Matthews because that was the only way to make them work. Still, it was ugly, nontrivial, and tended to screw up every few months. If I did it all over again (it was not my original design; I only fixed what was already there), I would have done it differently. In response to BASIC vs. ladder logic: both stink. The code is just as ugly either way. The "cleanest" form for writing protocol/communication code at a low level is to write it in reactor-based style with layers. Each layer is easiest to write in a class/object based system where you can achieve complete data encapsulation in each layer. That's how things like Wireshark and most protocol libraries are written these days. BASIC and ladder logic are quite foreign to those programming styles, so you are working an uphill battle. With some creative use of subroutines you can probably "fake it" but that's as close as you'll ever get. In my mind, there is almost no difference between writing the code in either one. There is no inherent advantage either way. The major advantage of the BASIC modules (other than lining AB's pockets) was always familiarity. PLC-5 and the newer Logix processors support Structured Text which is essentially based on Pascal which is familiar to PC programmers but totally alien to controls programmers. Supporting any of these languages was always done simply to provide a familiar environment for PC programmers. The one advantage that structured text has over ladder logic programming is that certain styles of programs which require extensive procedural approaches (running mathematical calculations with lots of loops like Fourier transforms for instance) was always cleaner, faster, and smaller in structured text.
1 person likes this

Share this post


Link to post
Share on other sites
Wow, dude you just blew me away. Awesome post again, Paul. This Paul is just going to borrow from his 401K to buy a G304K to mount on my front porch to irrigiate, secure and operate my star trek doors made from scraps...I have a ML1000 20AC In, 12 relay out that already runs my outside lights, and I have enough SVs and motion switches, just not enough time to get it all mounted and routed. I plan to have a keyless entry and pneumatic automatic sliding doors on my front entry porch enclosure project by summers end.

Share this post


Link to post
Share on other sites
Hi, Thanks for that I will take your advise and have a good look into all that has been mentioned and will let you know how I get on. In the short term I will use a panel view to get the main functions tested and gradually link in the AV as you suggest. That is if I can remeber my C++ Thanmks again

Share this post


Link to post
Share on other sites
Hi could you tell me where I could get the DF1 protocal from ? many thanks

Share this post


Link to post
Share on other sites
Knowledgebase on Rockwell's web site. Also google Lynn Linse.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0