I'm using a PM6000 to measure the DC input and AC output of an inverter to a 3 phase motor. I've had a large number of problems in the past the have come and gone seemingly mysteriously, but here are some that I'm staring down the barrel of at the moment. Assume that, for all of these, I have my DC input on Ch1, AC outputs on Ch2 and 3 (3P3 wiring), I'm reading results with a LabVIEW program by sending one concatenated string for measurements on each channel (ie., :FNC:CH2:WAT?;:FNC:CH2:VLT?;:FNC:CH2:AMP?;.....), and that I'm grouping all channels together (3P4W) in order to be able to quickly read values on both the input and output sides (I know that this is probably wrong, but if I separate them out into 1P2W and 3P3W groups then it takes a lot longer sending commands this way, and I find that doing a BRD? or FRD? query takes too long and I noticed that the drive output frequency returned severely lags the actual output frequency this way, plus the other engineers are finicky about seeing AC parameters on the DC channel and vice versa, which is what the BRD? and FRD? functions return - that is, all possible measured parameters applied to all channels - so I abandoned this approach. I'm applying what you'd normally apply to the drive output channels for all channels in this case, except for AC+DC coupling is set instead of just AC).
-When querying fundamental parameters (FND as opposed to FNC) on the AC channels but none on the DC channel, the program hangs up when trying to read the fundamental parameters. Is this to be expected? I suppose a work around for this would be to wire my AC output to channels 1 and 2 and DC to channel 3, as I query channel 1 first (which we're very unlikely to ask for fundamental parameters on if none are being measured on the AC).
-I'm finding that while measuring both the AC output of the drive and the output of a function generator, I'm getting 0 Hz back for the frequency (rarely it has gone to 2,000 Hz, which is well above anything we're measuring). The frequency source is set to current while measuring drive output, and also set to whatever I wire the function generator to. This is a new development - we were measuring frequency fine (except with the time lag) before about two weeks ago.
-We sometimes want to measure many harmonics (effectively get a spectrum). From what I've learned so far, using the approach of querying individual parameters (versus BRD? or FRD?) falls apart while doing this, as it takes quite awhile to send and receive commands to set the next harmonic, query (potentially) all five (voltage and current magnitude and angle and power magnitude), then set the next harmonic, and so on, up to, let's say, 100. Is the BRD? function the only effective way of getting many harmonics? Or is there something I'm missing in my individual string query approach?
-As I mentioned previously, I'm now trying the individual string query approach because it's much faster than using BRD? or FRD?, and also because the output frequency lagging the actual frequency by ~40 seconds is a dead giveaway that at least some of the data I'm taking isn't in sync with other measurements I'm taking on the system. It's also worth noting that, for example, if I run a torque vs. speed curve by incrementing the speed in small steps every ~4 seconds and then overlay plots of output frequency and motor speed versus time (scaled by number of poles and all that and neglecting slip), the output frequency isn't a straight time shifted line - instead, it looks like a step function, and the frequencies on one line segment are all exactly the same (ie., 20.482, 20.482, 20.482, 20.482, 20.482, 31.455, 31.455, 31.455, 31.455...). The number of points per line segment decreases as I increase the step time, and the frequency and scaled speed vs time graphs are almost line on line if I set the time step (time I give the program between sending a new speed command and querying the PM6000) to ~40 seconds. However, we're changing torques and speeds at ~5 second intervals. I've tried decreasing the averaging size with no luck. Is there any way to get rid of this lag? If so, this would alleviate all of my problems in this post (assuming the 0 Hz frequency returned problem went away, and I can easily write a subroutine that takes out the unwanted AC measurements on the DC channel and vice versa to satisfy the finicky engineers), as a 5 second time step is something we can definitely live with, and it'd be nice to configure the input and output channels as different groups (the way I should be doing it). My best guess is that I was onto something with making the average size small but something I'm missing that has to be reset.
-I recall having trouble with (what I call) the configuration stage (between initialization and the acquisition loop) that was alleviated by switching the order of what parameters (ie., filter settings, current and voltage range, coupling, etc.) were set. Is there a specific order in which these have to be set (ie., setting a group to PWM output then the LPF to 1 MHz is ok, but setting the LPF then the PWM mode will make it blow its cookies)?
-It seems that whenever I get inaccurate measurements (by "inaccurate" I mean WAY off, not just a percent or two), the frequency is pretty far off. My best guess is that all fundamental parameters need an accurate frequency to get accurate results (I can't see any way around this), but what FNC parameter calculations depend on frequency?
Thanks in advance!