Free Scada

i use Facon FBs series PLCs. can any one get me a free scada, a limited version with few tags is okay? This is for learning purpose.

rakesh
[email protected]

How about iFix? V3.5 springs to mind. You have unlimited tag usage for 2 hours. When it expires simply restart application. I know of plants who have there entire SCADA like this. One plant in particular hasnt even got a legitimate copy of iFix. Of course where data logging is required this woulds not suffice.

Citect have a driver for Facon FB40 PLCs.

You can download at www.citect.com

Thank you Francie. However I will check the availability of i Fix!

Thank you Bob. I have querried the website for the evaluation copy. It runs on physical I/O for 15mins. but seems okay for my application / requirement. Thanks a lot.

I think that InduSoft Web Studio has the largest evaluating period - 40 hours. It is enough to develop small application even for newbie.

This SCADA exists in two releases:
IWS v6.1 with visual basic support and
IWS v6.0 without visual basic support.

As for me, I hate VB for real-time purpose...

If you need absolutely free SCADA click here.

Not that I like to disagree but the Modicon version of CITECT has a 21 day eval period, fairly easy to get you hands on. This is called Vijeo CITECT. And if you are lucky enough you can manage a demo copy of CIMSCAN by CimTEchniques they have a 30 day eval period. Just some thoughts to throw out there. Have a nice day.

zova said:

I think that InduSoft Web Studio has the largest evaluating period - 40 hours. It is enough to develop small application even for newbie.

This SCADA exists in two releases:
IWS v6.1 with visual basic support and
IWS v6.0 without visual basic support.

As for me, I hate VB for real-time purpose...

If you need absolutely free SCADA click here.

Click to expand...

Vijeo Citect is the Schneider version that was developed for them when they bought Citect. Citect still operates independantly though and the Vijeo version is only available from Schneider. Citect is still available to download for free to allow one to evaluate and develop an application. Then you only have to buy the dongle when you install the job.


I was discussing this with the Citect Product Manager only yesterday when we were discussing development of a new driver and what it should be capable of doing. I do have quite a few inside contacts at Citect and have helped them out (and myself) before with testing a beta driver.

Here are somethings that you might want to forward to CITECT since you have some inside contacts. What they might want to consider is using some kind of code similar to that which KEPSERVER uses. They have plenty of built in tags which can be used to check communications between the shop floor device and the server software. At first I wanted to use this piece of software because in my opinion it would help in troubleshooting should anything go wrong. I mean you could bring up the OPC quick client to see if the data is indeed comming back to the server then you would know if the problem was in between the hardware and the server or the server and the client. But our IT staff thought this would complicate things, plus we could not browse the server, even had the tech support people at CITECT do a remote login but it would not browse the server, so the IT staff wants the device on the shop floor to communicate directly with the software. Here CITECT assisted and their MODBUS driver does the job quite nice. But like I said there are tags within the KEPSERVER program that would be a nice addition to the drivers in their own server.

BobB - What is your take on SCADA systems? If you are designing a system to do data collections and job assignments, how would you lay out the system? Being as you have been doing this probably far longer than myself, I mean I have only been on this path for about 8 months, first time doing a project of this magnitude, I thought maybe you could give some guidance and pitfalls to watch for?

Also in the citect software, maybe I did not make my question clear to the support engineer and thought maybe if I put it here you might know exactly how to translate it into what they understand.

Using Kepserver when I first started I put in one channel and one device. This worked out quite well. So to test the limitations of the software I put in another device in the same channel. Well this caused lags and delays. Not good for high speed applications. Upon doing research and communicating with the tech support at KepWare I found the best approach would be to have each device on its own channel. This way should a device go offline it does not affect any of the others.

In Citect they have different terms. They use Server, Port, Board, IO Server, and one other that I can not recall right now. But what I am wondering is how these terms relate to the terms from KepServer. Is the port the same as a channel and the board is just the hardware inside the PC or how do you translate from one to the other?

I ask this because I dont want to get into the same lags and delays as I did when I first started. So any hints, tips or suggestions are really welcome.

Thank you and have a great day.

BobB said:

Vijeo Citect is the Schneider version that was developed for them when they bought Citect. Citect still operates independantly though and the Vijeo version is only available from Schneider. Citect is still available to download for free to allow one to evaluate and develop an application. Then you only have to buy the dongle when you install the job.


I was discussing this with the Citect Product Manager only yesterday when we were discussing development of a new driver and what it should be capable of doing. I do have quite a few inside contacts at Citect and have helped them out (and myself) before with testing a beta driver.

Click to expand...

Citect have an OPC driver but that is not their preferred option (nor mine). They much prefer a specific driver for each device, sometimes through a manufacturers middle ware, but specific drivers are generally faster and more reliable.

At the moment they are developing a driver that has been tradiationally addressed by just about everyone using OPC. The driver under development will be a direct driver to the hardware instead of using OPC. I dislike OPC quite frankly and have grief with it more than once. The last time I was extracting information from building management system devices and a computer via OPC. Used to take about 5 minutes to pick up all the data when firing up the OPC server to the devices - slow as a wet week. The Citect OPC driver was very quick in getting the information out of the OPC server though. Used to finish up with bad values and all sorts of things until the OPC server got it's act together.

Hardware on the shop floor (I presume you mean PLCs) have there own checking bits and I also generally use these. In Citect there is a "kernel" - turn the kernel on and you can check all your comms there. As a matter of fact, in the example project there is a "utilities" page that can be used/modified and there is an "I/O" device info button that can be used for checking devices, cicode button, system info button - perhaps these will help but I generally use the kernel and have it logging all the time - open the log and decipher problems from there or send to Citect support and have them sift through.

The Modbus RTU driver is excellent and works extremely well. I have used it to fire panels many a time.

All other drivers I have used have been hardware specific drivers except for twice I have used OPC with mixed results.

When planning a system I first find out what the client requires in the way of pretty pictures, logs, alarm logs, trending, histrorical data etc. ThenI start planning from there.

When writing my PLC programs I arrange bit channels and word channels in the PLC to be as contigious as possible. This cuts down on "headers" every time the SCADA needs to read information from the PLC and maximises the speed at which the SCADA can get information out of the PLC network. Beware of boundaries though.

While writing the PLC programs I extract the addresses and descriptions of the I/O that is required for the SCADA and with Citect in particular I am able to open the "variable tag" data base with Excell and I then paste these from spreadsheet to data base spreadsheet and save lots of time. One must be very careful though not to change the width of the columns or Citect will not read the re-saved database.

At the same time I develop the graphics pages (unless they have been done before to seek approval from the client). The tags developed for the SCADA are then attached to the relevant bits on the graphics pages.

And so on.

Hope this helps.

As for the middle ware drivers I assume you mean something like KepServer. Is that correct? I ask this because Horner is the one who from my understanding contracted with KepWare to write the driver for their product. The one problem with using the manufacturers driver is the fact that at the time of this message their driver only supports one channel and one channel only. So unless I wanted the slow and lag response I had to choose something different. Well they do offer Modbus, within the Modbus they allowed multiple channels and so I am able to have one Channel per one device. This has improved effects. This is why I was wondering how the terminology used in Kepware correlates to the terminology in Citect. In Kepware they use channel and device, in Citect they use board, port, etc. So I was curious if the port setting was like the channel or the device in the kep product. I was also wondering if I am going to suffer lags. You see the client whom is asking for this project is also the same company I work for. And I personally have never done a task quite this large and complex. I have now been doing this for less than 1 year and have come a long way but I know I have lots more to learn. I have asked that we continue in our use of the KepWare product but the IT dept and MGMT said they would prefer direct communications. Which I have been able to make happen with the CITECT product. The only thing I have not yet figured out with the CITECT product is how to do some of the things which are done for you in the Kep product. One such thing is the _System._error flag in the Kep product. This is quite nice and alerts to a system comm error quite fast. Of course the other thing we have had trouble with is establishing a nice handshake between the Kep and the CItect. Everytime we established comms and we went to browse it would either lock up or crash. And it even did it to the tech who did a remote login to our machine. This was another reason it was requested that we eliminate the middle ware.

As for how I write my code in the PLC, Before I even begin writing the code I first of all have a couple of meeting with all the people in charge. From this I get a clear picture of what they want. What data they want where they want it, how they want to use, etc.. Then I sit down and using old school I draw up a flow chart. How one thing flows to another and so on, what happens on a yes(true) and what happens on a no(false). I do this for each segment of the program. Then I draw up a chart to couple all the parts together. I also get all the particulars of the device that will be used at the machine level. Layout of register, limitations of the registers, what system and other flags are avail. Then I lay all this information out and start writing my code. I usually write one segment at a time test and debug it then once I am happy it works do the next section. As for my IO layout, it is something that still sticks with me from my college days, I always layout my IO in contiguous memory. In this case I laid out the registers which will contain the programmed information in registers 200 thru 260 and I laid out the registers that will contain the data being presented to the SCADA software in registers 380 thru 460. I also left room for further improvments and changes just in case. The other thing I did was for the bit IO, I laid that out in M1 thru M32 although right now I only use upto M18 it allows for future growth.

Using the Kep product I was able to establish communication and I used their diagnostic feature and I know that to do a complete scan of all the tags, 44 in all, it takes an average of .8 seconds. But I hope to get that down even lower when instead of addressing each of the bits group the bits together in words and send it that way then decode it in the software.

And YEs when I refer to shop floor I am talking PLC.

As for the developement stage, well that is where I am at right now. I am in the process of developing the user screens and such for the SCADA. One thing I wish I had done when I was a lot younger was take other languages besides ASM and Pascal. I wish I had take VB because then I would a lot further along then I am now because all the HMI packages that I have tested thus far all have VB scripting and allow such things as actual code. But alas hindsite is always 20/20.

Hope this answers your questions. Have a great day.

BobB said:

Citect have an OPC driver but that is not their preferred option (nor mine). They much prefer a specific driver for each device, sometimes through a manufacturers middle ware, but specific drivers are generally faster and more reliable.

At the moment they are developing a driver that has been tradiationally addressed by just about everyone using OPC. The driver under development will be a direct driver to the hardware instead of using OPC. I dislike OPC quite frankly and have grief with it more than once. The last time I was extracting information from building management system devices and a computer via OPC. Used to take about 5 minutes to pick up all the data when firing up the OPC server to the devices - slow as a wet week. The Citect OPC driver was very quick in getting the information out of the OPC server though. Used to finish up with bad values and all sorts of things until the OPC server got it's act together.

Hardware on the shop floor (I presume you mean PLCs) have there own checking bits and I also generally use these. In Citect there is a "kernel" - turn the kernel on and you can check all your comms there. As a matter of fact, in the example project there is a "utilities" page that can be used/modified and there is an "I/O" device info button that can be used for checking devices, cicode button, system info button - perhaps these will help but I generally use the kernel and have it logging all the time - open the log and decipher problems from there or send to Citect support and have them sift through.

The Modbus RTU driver is excellent and works extremely well. I have used it to fire panels many a time.

All other drivers I have used have been hardware specific drivers except for twice I have used OPC with mixed results.

When planning a system I first find out what the client requires in the way of pretty pictures, logs, alarm logs, trending, histrorical data etc. ThenI start planning from there.

When writing my PLC programs I arrange bit channels and word channels in the PLC to be as contigious as possible. This cuts down on "headers" every time the SCADA needs to read information from the PLC and maximises the speed at which the SCADA can get information out of the PLC network. Beware of boundaries though.

While writing the PLC programs I extract the addresses and descriptions of the I/O that is required for the SCADA and with Citect in particular I am able to open the "variable tag" data base with Excell and I then paste these from spreadsheet to data base spreadsheet and save lots of time. One must be very careful though not to change the width of the columns or Citect will not read the re-saved database.

At the same time I develop the graphics pages (unless they have been done before to seek approval from the client). The tags developed for the SCADA are then attached to the relevant bits on the graphics pages.

And so on.

Hope this helps.

Click to expand...

Scada package

Hi,
Try this one, It's not free but very cheap.
You can download the whole thing and use it with little restrictions.

http://www.mmiopc.com/products/PowerHMI.htm

Hope it can serve U

As for the middle ware drivers I assume you mean something like KepServer

Click to expand...

No - I prefer not to use OPC. I am referring to middle ware like Omron FINS Gateway, RS Links etc. Middle software provided by the PLC manufacturer that contains a set of hooks for the SCADA guys to write a driver. By the way, I have one Citect package running on Omron Sysmac Link via Omron FINS Gateway wher Citect is reporting in excess of 13,000 digital and 200 word reads per second. I do not believe you will get that sort of performance out of OPC. We are trending frequency every 100 milliseconds - miss a few but not many.

I might add that there are over 3500 tags in the SCADA system extracting and writing data from and to 9 PLCs. It fairly hoots along. This is in addition to a pile of stuff that is peer to peer on the same network between the 9 PLCs. 4 PLCs are exchanging some 1500 words of data betwwen them as well. Sometimes the netwrok does slow down of course dependant on the amount of data being transmitted at the time.

I can also refer to other systems with extremely high throughput rates using the same comms system.

44 in all, it takes an average of .8 seconds

Click to expand...

That is what I mean, it is S L O W.