I'm not sure if this is the right place to post this (I'm fairly new, but Stackoverflow and Superuser suggested this site for my question), but here goes.

I currently have the following:

  • A frontend - made with WPF
  • A Dll
  • An IO-server - Hardware.

The Dll contains ways of communicating with the IO-server, and the frontend should be able to control when to open/close and also read from the IO server. I now need to make a new program to handle this.

The way it should operate, roughly, is:
You click a button on the frontend and it sends a tag (e.g "qw450") to the program i'm about to make. This then converts the tag to a function (so depending on the tag it does something different). Then it calls the corresponding function and updates the IO server acordingly. This should go both ways. So if the IO server gets a signal, the "tag interpreter" should send a tag to the frontend and update some visuals (e.g change color or show numbers)

So far I've thought of 3 different solutions and would like to know which is better and why. The most important thing will be the speed of each operation as it might be used to control emergency stops and such.

[EDIT: Added images]

Solution 1: Standalone program
Create a new program and have that implement the DLL. Then keep the current frontend and have it call the new program.

Standalone program

Solution 2: Expand the frontend
Keep the current setup and insert the way to communicate into the frontend program (in a dal layer)

Adding it to the backend

Solution 3: Create another dll
Create this as a dll and have to current frontend implement both the dlls.

As a DLL

I really hope this makes sense to you and you would like to help me. And of course if there is an even better solution i would love to hear it!

  • 3
    All of these options are valid (though I would suggest that 2 and 3 should go hand in hand). The question is what you justifiably need to use. This almost entirely hinges on the size and scope of your application. For example, additional applications are good if you want to either centralize many clients, or you want to do some gatekeeping (e.g. not giving the front-end the keys to the IO server). – Flater Oct 22 '18 at 14:09
  • Also, is this related to OPC? Have you looked for existing solutions to your problem? I've developed several OPC applications and almost always, there was already an existing tool to do a similar job. – Flater Oct 22 '18 at 14:10
  • @Flater Thank you for your answers! it is indeed OPC and i will be looking for some tools that might help. You said 2 and 3 should go hand in hand. Does that mean that you suggest creating another dll and communicate through that instead of just calling the current dll i have directly from the dal layer? I'm not able to up your comments but if you create an answer i'd be happy to vote for it :) – Stephan Fuhlendorff Oct 23 '18 at 7:04
  • What I meant more is that when you expand the frontend (solution), you should put your OPC wrapper in a separate database, at least as a matter of good practice (so it can easily be swapped out at any point in the future). – Flater Oct 23 '18 at 7:08
  • @Flater Thank you very much. I feel that i need to do some more digging in the OPC area. Thank you for pointing me in the right dircetion :) – Stephan Fuhlendorff Oct 23 '18 at 7:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.