Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

ENET-232 with multiple user accounts

We have an ENET-232/4 that is having difficulty when some users log on to the machine. I installed the software (with admin rights) and can see the device, but if another user logs on and tries the Diagnostics program, an "error reading registry" occurs and the additional remote ports are not seen.

Computer is running Win 2K.

Note that the nisdsusr file was upgraded to try and fix another problem (it resulted in different problems that I'll need to address when I get time). Ref #5981-SMR353

Thanks!
Jim Daniels
0 Kudos
Message 1 of 11
(4,807 Views)
Do the other user have admin privs?
0 Kudos
Message 2 of 11
(4,806 Views)
>Do the other user have admin privs?

Yes, they do.

Jim
0 Kudos
Message 3 of 11
(4,806 Views)
Interesting. We verified that users who are not administrators do see this error. However, users that are administrators (added to the administrator group) don't see this problem. Is the diagnostics program the only thing not working for you - can you communicate with the serial ports?

We're going to take a look at the diagostics program and see what can be done - it should work for all users, though is probably failing on one or two keys that are only accessible to administrators.
0 Kudos
Message 4 of 11
(4,806 Views)
>Is the diagnostics program the only thing not working for you - can you communicate with the serial ports?

Nope, the ports are not seen by Labview when the other user logs on. I could care less about the diagnostic program, it was just a convenient method to indicate the problem, or so I thought.

I received further information and the problem is even more bizarre - when the other user logs on, one of the ports is available and functions fine, but another cannot be seen. Pulling down the visa constant in the Labview panel had no valid (not greyed out) entries for the ports. I'm at a loss as to why one of the ports functions at all so I investigated the code. The port that functions uses the old serial calls whereas the non-funct
ioning port uses VISA.

Sorry I didn't have all the information in the first post.

Jim
0 Kudos
Message 5 of 11
(4,806 Views)
I'll agree that it's odd behavior (as well as frustrating). Just to verify - all users in question are a member of the Administrators group - right? (Not "Power Users" or "Restricted Users" under the user manager). I'm wondering if local user profiles are somehow affecting the behavior. Are you doing anything 'different' regarding user profiles? Have you tried installing as administator (not a user with admin rights)?
0 Kudos
Message 6 of 11
(4,806 Views)
Chris, I'll have to get back to you in a few days with some definitive answers to the last post - the system is in a remote location and the next test is not until Thursday I think. At that time I will confirm the user in question has admin rights.

I can, however, confirm that the software was installed under a user account with admin priveleges, not with the administrator account. I have not tried that. There should be no funnies as far as user profiles that I am aware of.
0 Kudos
Message 7 of 11
(4,806 Views)
Keep me posted, and in the meantime we'll check out a few things. Thanks for the report.

Out of curiosity - what was the other behavior that you were experiencing?
0 Kudos
Message 8 of 11
(4,806 Views)
> Out of curiosity - what was the other behavior that you were experiencing?

I wanted to instrument the Labview code to get more details first, but basically the connectivity just stops after some period of running. We often go for an hour or more then the serial write calls start to fail. Restarting Labview clears up the problem and the communications are fine. I seem to remember just stopping the run and restarting also fixed the problem but I am not 100% sure of that case.

This is a very slow bandwidth link and is just used to issue commands to an embedded system controlling power switches, which are rarely changed. One possible clue is that I ignore all incoming data from the system, only
issuing write commands.

Jim
0 Kudos
Message 9 of 11
(4,806 Views)
I was wrong again - the user having trouble is not in the administrator group. I know we changed this in the past, but it somehow was negated recently, maybe when a round of forced password changes was required. At any rate, I can add the user to the admin group. Will this be a continuing requirement, or will ordinary users eventually have access as well?

On the other problem, I added some error logging to the write vi so that maybe I can capture an error code when the link goes silent.

Jim
0 Kudos
Message 10 of 11
(4,806 Views)