I am developing a system to test a system that includes software running on a PC, a S7 PLC, and several sensors. I am using a cRIO to simulate the digital and analog I/O to the PLC and OPC for the computer. That part is working great. The next step is to simulate an Endress+Hauser PROMASS 83 DP which is a profibus slave to the PLC. My first go at this was to use the cRIO PB module from Comsoft. But, correct me if I'm wrong, it seems you have to import the module's gsd to the PLC programming to get it working, which doesn't fit one of the constraints I have to work under, which is I can't make any changes to the system I'm testing to accommodate the simulator.
So basically, I need to be able to communicate with the PLC over Profibus in a way that it thinks I am the Promass 83. Is this possible? If so, how might I go about doing it?
If you were using the Comsoft module as the master you would need to import the gsd for whatever device you are having it communicate with. Since you are talking about doing the opposite, and having the Comsoft module be the slave, whether or not you need to load a gsd file to your PLC should depend on how your PLC is programmed. If it is programmed in such a way that it will be able to talk with the Comsoft module without needed the gsd file, you may be in luck. As far as emulating the Promass 83, I am not familiar with that device, but if it handles inputs and output the same way the Comsoft device does, then you should be able to write a program in LabVIEW that would mimic the behavior of the Promass 83. To do this, you would need to know how the Promass 83 responds to any inputs you may be sending it.
In what way would the PLC have to be programmed to not need the gsd file? It was programmed by importing the gsd files for the two profibus slaves it communicates with.
The answer I am getting from comsoft is that the module has a unique ID which cannot be changed. So if it's this ID that the PLC looks for to communicate over profibus, I'm out of luck it seems. Is this the case, or does that depend on how it's programmed as well?
To answer your first question, you would need to match exactly the behavior of the device you are trying to emulate, and then use that device's gsd file.
In a response to your second point, I believe you are correct and that this ID cannot be changed. With that limitation you very well may be out of luck since you cannot emulate perfectly the device that you are trying to simulate. To get this working you would need to change some things in the PLC as well, which sounds like it defeats the purpose of this application.
Unfortunately I am not aware of a card with this capability that can work with LabVIEW at this time.
If you dont' mind, can you please share some detailed steps ? I know this has been long time but I am stuck with driver steps and manufacturer tech support is not that useful.