IviSwtch Disconnect / DisconnectAll return value.

[MarkCO]

I am creating an IviSwtch driver for use with niSE which controls many switches that have no 'Disconnect' state.  These are switches such as SPDT switches which always have a connection from Common to Port 1 or Port 2, but is never disconnected from both.  Setting the disconnected state to one position or another may erroneously connect unintended paths in the system, and thus I have decided to implement the 'Disconnect' and 'DisconnectAll' functions as no-operation; they do nothing.

The IviSwtch Class Specification, sections 4.3.3 (Disconnect) and 4.3.4 (DisconnectAll) specify a warning Completion Code of 'Path Remains' if all or part of the path was not disconnected.  What does niSE do if a warning Completion Code of 'Path Remains' is returned from Disconnect or DisconnectAll?  Does niSE ignore IviSwtch warnings, or will it return an error from niSE_Disconnect / DisconnectAll?

Cheers!
Mark

[Srđan_Zirojević]

Mark,

short answer: niSE will ignore it.

I see that you started making some design decisions regarding the behavior of your driver. Here is the short app note that may help you in some of those decisions. (See section 6: Special considerations for form C relays).

Best regards,

Message Edited by Srđan Zirojević on 03-23-2007 02:33 PM

[MarkCO]

Thanks for your prompt response, Srdan.   I was looking over the niSE requirements in the link that you posted, and I have a few more questions, specifically regarding the following two requirements:

·  mySwitch_Connect, (shall set the “connected” state in the driver such that a successive connect call with the same channels will give an error)

·  mySwitch_Disconnect (shall change the state in the driver so the channels are marked as not connected and return an error if the two channels are not connected)

These rules imply that there must be a Disconnect call for every Connect call on a switch.  For our system it does not really make any sense to disconnect a switch (there is no disconnected state), and furthermore, there are situations in our system where multiple paths contain the same switch.  Although the IviSwtch class specification does not allow for implicit disconnections, this system does not really have to be class compliant, it just has to work with niSE.  So I would propose to always maintain an IviSwtch state of 'Disconnected' for all IVI Channel connections in the system, regardless of the actual hardware state.

The IviSwtch functions would then have the following behavior using both simulation and non-simulation modes:

Connect would change the hardware state (if not in simulation mode), but not change the IviSwtch state and would always return success.  Thus Connect could be called multiple times consecutively.

Disconnect and DisconnectAll would not change hardware state or the IviSwtch state and would always return 'Path Remains' warning.

SetPath would always return success if the syntax is valid and the path is possible, regardless of existing connections- since the IviSwtch state is always 'Disconnected' then there are never any existing connections.

GetPath would have no way of knowing whether a path was currently connected, and so would return the path if it is possible to create, regardless of the connection state.

CanConnect would always return true if the path is possible to create, regardless of the connection state.

Will the defined IviSwtch behavior work with niSE?

Thanks!

Mark

PS- I had to write this message twice because my session timed out before I could post the first time, and when I clicked the ‘back’ button my message was gone- that was a bit annoying to say the least.  The second time around I entered the message in Word and then pasted into the message body.

[Srđan_Zirojević]

Mark,

I was thinking about your proposal and here's what I came up with as a suggestion:

- write an IviSwtch-compliant interface (have the Connect, Disconnect, DisconnectAll, SetPath, GetPath, and CanConnect functions behave as prescribed)
- add two more instrument-specific functions, e.g. Open and Close relay, or something like that, to your instrument driver and recommend those for use with your specific module. You may even decide to demote Connect and Disconnect and the rest from the function panels.documentation etc.

This way, you will present the interface you want to the direct clients of your driver, and you will preserve the coherent behavior of switch executive with respect to niSE clients.

My thoughts went along the lines of changing the API of your driver (here by the API I mean both the function signature and function behavior), and where I ended up was the change of behavior of switch executive API. That was something I could not agree with.

For example, if you went ahead with the implementation of your driver as suggested, it might have worked today in some cases, but it would be very dangerous to assume that future versions of niSE would produce the same behavior. You may start getting errors in some cases, and other undesirable behaviors in other. niSE does keep track of the state of switches itself (in some cases) and you may end up with error cases where you would not expect them. At the same time, you will end up with no errors when you would expect them, again for certain use cases.

I agree that modelling of form C relays with Connect and Disconnect paradigm isn't the best choice, as it has its own share of issues regarding implicit connections, but modifying the IVI driver's behavior would only introduce more uncertainties and would throw off all of us that got used to one meaning for the connect and disconnect functions...

hope this helps!


For all these reasons,

[Srđan_Zirojević]

oh, by the way,
you can post to the developer forum feedback thread about your experience with the session timeout:-)

-Serge

[MarkCO]

Hi Srdan,

Thanks again for your response and suggestions.  Unfortunately my problem is a bit larger than I have described so far, perhaps a more detailed description will give you some insight as to why I proposed the implementation that I did:

The bad news:

1)  This is an RF switching tray with 20+ switches including SPDT (form C), SP4T, SP6T, Transfer switches (think of a box with one position being two horizontal connections and the other being two vertical connections), Terminated 4 port switches, and Matrix switches (where any one of six ports can connect to any other).  NONE of these switches has a state in which it is 'disconnected'.

2) It is a customer requirement to use niSE to control the switches.

The good news:

3) The IviSwtch driver will only be used in this particular application and does not have to be a general use IviSwtch driver.  It just has to work with niSE- niSE is the only client for this driver.  Given the constraints that you and I have been discussing, I might even be able to get the customer to agree to using this driver with one specific version of niSE (maybe).

4) This application requires only the following functionality from niSE:

- create hard wires between switches  to specify the switching topology

- create path definitions from one side of the tray to another via switches and hard wires.

- connect pre-defined paths; paths are not created ‘on the fly’, but prior to run time.

In light of this further information, how might you suggest that the IviSwtch driver be implemented for use with niSE?

Thanks again for all of your help!

Mark

[Srđan_Zirojević]

Mark,

I gave it some more thought, and I could not convince myself that, given the end result, developing a driver according to your proposed behavior would give you any benefit over developing a straight-IVI switch driver (even though Disconnect doesn't do much on it). Yes, transfer switches do require some extra thought as they tend to be tricky, but in the end, your goal is to find a path from point A to point B in your 20+ device fixture, and that is where you correctly recognized that niSE will help you out.

I took into consideration the fact that niSE is developed with heavy reliance on the underlying correct behavior of IVI Switch compliant drivers. Sometimes, niSE will rely on that when making routing decisions, and at other times, niSe's own 'intelligence' will take over before passing calls down to underlying IVI drivers, making some decisions for the client. Both algorithms (niSE's and IVI's) are built on top of the very similar (if not identical) assumptions, and hence the transparency for the niSE clients - as it is not always clear who is making routing decisions. Most of the time it is niSE (whenever you route across multiple devices) while at some points in time the specific driver ultimately makes the inter-device routing decisions.

If you go ahead with your proposed architecture, you will end up with the niSE clients sometimes being able to leverage the same behavior (i.e. the niSe clients will be able to call niSE_Connect functions and have relays implicitly switch to other paths, while destroying previously connected paths), but that would be short-lived as niSE session itself will not eliminate those connections, effectively preventing you from connecting the original path again.

So, to elaborate on a simplest switch:

Let's say you have one SPDT relay, with channels COM, NC, and NO. Assume device name to be Dev1, and niSE channels to be Dev1/COM, Dev1/NC and Dev1/NO. For simplicity, I will omit Dev1 from futrher text.

On the specific driver, IVI driver would allow prefix_Connect(Com, NC) but at that time Connect(Com, NO) would return a resource-in-use error.
Your proposal is to allow Connect(COM, NO) and have the driver flip the relay on the switch. I understand.

Assume now that your application calls Connect(com, nc), then Connect (com, no) and then Connect (COm, NC) again. I am assuming your proposed architecture, IVI would require a disconnect in between.

That would work, right?

Now, assume you put this driver in works with niSE. niSE routing engine would allow you to connect COM to NO, it would also allow you to connect COM to NC if you requested such path (as your driver would say that COM and NO can connect, and both set path and connect calls would succeed, with GetPath returning COM->NO as a path).

If your user now wants to call niSE_Connect (COM->NC), then niSE_Connect(COM->NO) and then niSE_Connect(COM->NC) again, without calling disconnect on niSE in between the calls (which by the way would be required if the underlying driver were ivi-compliant), then the end result would be that COM is connected to NO.without any reported errors - obviously wrong.

Why? That's because niSE keeps track of connected routes, and it notices that a route between COM and NC already exists, and it hasn't been disconnected. Therefore, niSE will nicely decide that there is no need to call the underlying driver (that's one of the features of niSE, to allow multiconnect of routes, where we circumvent IVI's prohibition of calling connect on the same route twice). So, your ultimate client will HAVE TO perform Disconnect calls when using niSE API even if your underlying driver does not have that requirement.

This is not the only case where niSE would intercept your intended behavior and turn it upside down. This was just an illustration on why it may not be a good idea to try to shoehorn a behavior under niSE even if your limited test coverage ends up showing correct results on the surface. (And it is very hard to write a complete coverage tests as the number of channels goes up).

So, I am willing to offer some extra help when addressing individual decisions on how to make each topology into a nice IVI -compliant driver (we've done them all I believe here at NI, so we'll be able to offer at least equally good solution to you).

At this time, although I agree with you that the model of required explicit disconnects is not the best interpretation of certain topologies (or even not a good one) I believe that I've convinced you to drop the idea of allowing implicit disconnects in the driver, if it will be used with niSE.

If you have any further questions or other valid points I failed to recognize, please feel free to comment. I'm only afraid that going down the other path will take about the same time to develop, will take the same time to test the driver itself, but will take an order of magnitude more time to test the niSE layer that you will no longer be able to assume correct in all cases. The other side is the future upgrades of niSE, especially those that eliminate possible bugsin the current version (yet unknown at this time, but the ones that really fix issues you ran into) or silly things such as Win64 VISTA support etc. where the behavior might change for such non-standard use cases such as your proposed one.

br,

[MarkCO]

Hi Srđan,

You wrote:

---

Srđan Zirojević wrote:
At this time, although I agree with you that the model of required explicit disconnects is not the best interpretation of certain topologies (or even not a good one) I believe that I've convinced you to drop the idea of allowing implicit disconnects in the driver, if it will be used with niSE.

---

Yes, indeed, you have convinced me that implicit disconnects in the IviSwtch driver are a bad idea.  Thank you for taking the time to explain the state tracking that niSE does and the reliance upon conformance to IVI standards.

So to summarize, my approach to driver development will be to follow the requirements outlined in the document:

http://zone.ni.com/devzone/cda/tut/p/id/3449

The operation of the Disconnect and DisconnectAll functions will be to mark the connection as 'disconnected'- even though no change is actually made to the hardware- and return the MYSWITCH_WARN_PATH_REMAINS  warning.  The client will then necessarily need to call Disconnect for every Connect call.

Thanks again for your time and information. 🙂

Cheers!

Mark