AnsweredAssumed Answered

Setting TraceTitle property to any value turns on test port power

Question asked by andeezlemoyo on Nov 11, 2014
Latest reply on Nov 17, 2014 by jvall

Like • Show 0 Likes0
Comment • 8

Hi All,

I encountered some alarming behavior tonight, I am working with an 2-port E8362C, running firmware version, A.09.42.22. Alarming because I'm using a booster amp and it was on at the time. I'm monitoring power with an independent N1913A power meter.

From a user preset with test port power OFF, default power -25 dBm, with power offset of +25 dBm, which puts the source level at -50 dBm, using COM, I created a measurement and then I dabbled with changing the TraceTitle property of the measurement, as soon as I set the title to, "asdfasd," the PNA suddenly turned on the port power, IGNORING my offset. My aforementioned independent power meter was reading ~24 dBm and holding quite steady. Once I triggered a sweep, the power level returned to where I expected it to be. My power offset averages ~25 dBm . Very strange. Glad I didn't blow anything up. Fortunately port 1 was only connected to a U2000A power sensor and not my N4691B ecal module. Yikes.

Everything works as expected, and needed, until I set the trace title property. I wonder if anyone can reproduce this behavior. It seems like a bug. One thing for sure, I won't "dabble" anymore with the booster amp powered up, duh. But the question remains why the power turned on and the power offset was ignored?

Thanks for any help,
Andy

No one else has this question

Outcomes

jvall

Nov 12, 2014 1:45 PM

That *is* alarming!
I will look into it immediately and post my findings here.

Can you recall your Preset state, then save it as a .csa file and post that here.
Also helpful might be a .csa file after you enter the title.
And does it do the same if you manually type in the title?

I have tried a few things but can't seem to duplicate it yet...so the .csa files would help.

Actions

andeezlemoyo Nov 13, 2014 10:28 PM

Hi jvall,

I noticed a lot of strange behavior tonight. Like debug.assert(PNA.Channel(15).channelnumber), creates a channel 15. (15 is arbitrary.) The documentation states that you have to check that it exists.

I don't know if it's good to create the channel that way.

I also can see that time and again, my PNA power is turned on, even though the PNA.SourcePowerState returns False. If I set PNA.SourcePowerState=False, the power turns off. It is definitely real.

It seems intermittent and I'm not able to reproduce deliberately, but it keeps happening with no rhyme or reason yet that I can tell.

I know it's causing me a headache.

It's doing it right now , I've attached a .csa. (there are 2 channels, the second I added after the power turned on.)

Thanks,

Andy

Edited by: andeezlemoyo on Nov 13, 2014 10:26 PM

Edited by: andeezlemoyo on Nov 13, 2014 10:27 PM

Attachments

forjvall.csa23.2 KB

Actions

jvall

@ andeezlemoyo on Nov 13, 2014 11:04 PM

I am taking Friday off (unexpected babysitting duty), but will look into it on Monday....unless someone else beats me to it.

Actions

Dr_joel

@ andeezlemoyo on Nov 14, 2014 1:13 PM

This, and your other post, leads me to believe your pna proxy doesn't match the fw rev. When you install PNA it should install the proxy on the PNA for you to run on your PC.

the fact that commands to do one thing (change title) do something else (turn on power) is indicative of this type of issue. I've also forward it to a guy who actually knows something about what I just said (I don't know nothin' about COM).

Actions

jvall

@ Dr_joel on Nov 14, 2014 3:13 PM

While my grandchild is sleeping, I should chime in.

I am assuming your COM commands were issued from a PC and not from within the PNA itself. If so, you are using DCOM. If your are issuing the command from within the PNA's CPU, then you are using COM.

For DCOM to work properly, you must copy the PNAproxy.exe program from the Automation directory in the PNA to your PC, typically via a pen drive. You must then execute the PNAProxy program on your PC. That will get everything "sync'd up". Have you done that already?   *You should do that each time you update firmware* because new commands may have been introduced and/or changed.

If you are issuing the command from the PNA itself, then something is very strange.
Again, I will look into this on Monday, but in the meantime, let us know from where you are running your program.

Actions

andeezlemoyo @ jvall on Nov 14, 2014 4:19 PM

Hi All,

I'm using DCOM. I uninstalled the previous PNAProxy.exe, ran the delete registry keys utility found here in the posts, and then copied the new proxy version to the remote PC, and executed it there.

Before I reinstalled, I made sure all traces of the files were gone from the PC. And then reinstalled the proxy.

I still experienced the same behavior.

I found that if I issue a PNA.SourcePowerState = False after running the offending blocks of code that it quells the problem. When I get time, may be a while, I will try to put some code together to reproduce the problem.

Thank you,

Andy

Actions

jvall

@ andeezlemoyo on Nov 14, 2014 8:17 PM

Well, with that additional information, it is still all very confusing...and still alarming. I will confer with others on Monday.

Actions

jvall

@ jvall on Nov 17, 2014 2:31 PM

I am unable to duplicate this. As I have said many times in the past, duplicating the issue is 90% towards solving it.

Some questions and comments:

1. Can you try your same program but this time run it from the PNA. This eliminates any DCOM issues.
2. Are you finding this issue while developing the program (i.e. within the IDE) as opposed to just running the final .exe.
3. If you see this in the IDE, can you install your development program on the PNA itself and try it from there?
4. Can you uninstall the PNA application using Add/Remove and then reinstall it again?

I am running out of ideas.

Actions

8 Replies

jvall Nov 12, 2014 1:45 PM
Mark Correct
Correct Answer
That *is* alarming!
I will look into it immediately and post my findings here.

Can you recall your Preset state, then save it as a .csa file and post that here.
Also helpful might be a .csa file after you enter the title.
And does it do the same if you manually type in the title?

I have tried a few things but can't seem to duplicate it yet...so the .csa files would help.
Like • Show 0 Likes0
Actions
andeezlemoyo Nov 13, 2014 10:28 PM
Mark Correct
Correct Answer
Hi jvall,

I noticed a lot of strange behavior tonight. Like debug.assert(PNA.Channel(15).channelnumber), creates a channel 15. (15 is arbitrary.) The documentation states that you have to check that it exists.

I don't know if it's good to create the channel that way.

I also can see that time and again, my PNA power is turned on, even though the PNA.SourcePowerState returns False. If I set PNA.SourcePowerState=False, the power turns off. It is definitely real.

It seems intermittent and I'm not able to reproduce deliberately, but it keeps happening with no rhyme or reason yet that I can tell.

I know it's causing me a headache.

It's doing it right now , I've attached a .csa. (there are 2 channels, the second I added after the power turned on.)

Thanks,

Andy

Edited by: andeezlemoyo on Nov 13, 2014 10:26 PM

Edited by: andeezlemoyo on Nov 13, 2014 10:27 PM
Attachments
- forjvall.csa23.2 KB
Like • Show 0 Likes0
Actions
- jvall @ andeezlemoyo on Nov 13, 2014 11:04 PM
  Mark Correct
  Correct Answer
  I am taking Friday off (unexpected babysitting duty), but will look into it on Monday....unless someone else beats me to it.
  Like • Show 0 Likes0
  Actions
- Dr_joel @ andeezlemoyo on Nov 14, 2014 1:13 PM
  Mark Correct
  Correct Answer
  This, and your other post, leads me to believe your pna proxy doesn't match the fw rev. When you install PNA it should install the proxy on the PNA for you to run on your PC.
  
  the fact that commands to do one thing (change title) do something else (turn on power) is indicative of this type of issue. I've also forward it to a guy who actually knows something about what I just said (I don't know nothin' about COM).
  Like • Show 0 Likes0
  Actions
  - jvall @ Dr_joel on Nov 14, 2014 3:13 PM
    Mark Correct
    Correct Answer
    While my grandchild is sleeping, I should chime in.
    
    I am assuming your COM commands were issued from a PC and not from within the PNA itself. If so, you are using DCOM. If your are issuing the command from within the PNA's CPU, then you are using COM.
    
    For DCOM to work properly, you must copy the PNAproxy.exe program from the Automation directory in the PNA to your PC, typically via a pen drive. You must then execute the PNAProxy program on your PC. That will get everything "sync'd up". Have you done that already?   *You should do that each time you update firmware* because new commands may have been introduced and/or changed.
    
    If you are issuing the command from the PNA itself, then something is very strange.
    Again, I will look into this on Monday, but in the meantime, let us know from where you are running your program.
    Like • Show 0 Likes0
    Actions
    - andeezlemoyo @ jvall on Nov 14, 2014 4:19 PM
      Mark Correct
      Correct Answer
      Hi All,
      
      I'm using DCOM. I uninstalled the previous PNAProxy.exe, ran the delete registry keys utility found here in the posts, and then copied the new proxy version to the remote PC, and executed it there.
      
      Before I reinstalled, I made sure all traces of the files were gone from the PC. And then reinstalled the proxy.
      
      I still experienced the same behavior.
      
      I found that if I issue a PNA.SourcePowerState = False after running the offending blocks of code that it quells the problem. When I get time, may be a while, I will try to put some code together to reproduce the problem.
      
      Thank you,
      
      Andy
      Like • Show 0 Likes0
      Actions
      - jvall @ andeezlemoyo on Nov 14, 2014 8:17 PM
        Mark Correct
        Correct Answer
        Well, with that additional information, it is still all very confusing...and still alarming. I will confer with others on Monday.
        Like • Show 0 Likes0
        Actions
        jvall @ jvall on Nov 17, 2014 2:31 PM
        Mark Correct
        Correct Answer
        I am unable to duplicate this. As I have said many times in the past, duplicating the issue is 90% towards solving it.
        
        Some questions and comments:
        
        1. Can you try your same program but this time run it from the PNA. This eliminates any DCOM issues.
        2. Are you finding this issue while developing the program (i.e. within the IDE) as opposed to just running the final .exe.
        3. If you see this in the IDE, can you install your development program on the PNA itself and try it from there?
        4. Can you uninstall the PNA application using Add/Remove and then reinstall it again?
        
        I am running out of ideas.
        Like • Show 0 Likes0
        Actions

Setting TraceTitle property to any value turns on test port power

Outcomes

Attachments

Related Content

Recommended Content