FlexLogger Plugin Debug

[JW-JnJ]

I nearly have a flexlogger plugin working that sets up a serial instrument. However, I keep getting errors that don't show up in the PluginEnvironmentSimulator. The error appears once a second for a split second, then goes away. There is no error.txt text file that appears in the plugin directory (C:\Users\Public\Documents\National Instruments\FlexLogger\Plugins\IOPlugins\FlexLogger Mark10)

The weird thing is the data actually shows up once a second. If the VISA read in Process.vi were erroring, I would expect to get no data.

The instrument VIs that I wrote actually works when called in LabVIEW in a simple application (TEST- Read info.vi). It also works in the Simulator and the data shows up as expected.

So my questions:

1. Is there a reason I can't find the error.txt so i can debug this myself?
2. Is the Test Start and Test Stop notification only called when the test is run, or is it called during idle UI updates? (I tried to ignore errors while not "running")
3. Is Process.vi the only method that is called during UI idle updates? Is there another method that can possibly be causing this? (i.e. is it reconfigured every second?)

[Frisbee]

Hey Josh,

1- The error.txt is mostly used to report problems on plugin load - it does not contain the errors reported in FlexLogger via the Errors and Warnings pane.

2- The start and stop notification are only called on Test start and stop. Making changes to your plugin's UI (ex: changing a plugin-level parameter) will cause the plugin to run Configure Session.vi. 

3- If there are no parameter changes, then Process.vi and Handle Notification.vi should be the only VIs running in your plugin.

I will take a look at your plugin and come up with some troubleshooting/error squashing recommendations 👍

[Frisbee]

I expect the errors you are seeing are coming from the VISA reads in Process.vi.

Process.vi reports errors and then continues running. I did some super simple experimentation saw an error thrown by one run of Process.vi get cleared when a subsequent run completes successfully.

As a simple test, what happens if you unwire the error terminal from your Read Available.vi in Process.vi? Do you see your plugin successfully reporting the instrument's values?

Logging the errors to text file in Process.vi and Configure Session.vi would allow you to isolate the source of these errors.

[JW-JnJ]

Oh, good idea. Don't know why I didn't think to create an error log.

Now, here's the fun part. I open the file in Initialize, close in Finalize, and write any errors in Process (just after read) and Configure within an error case structure. The error writing makes sure to write a simple line first, then format the error (I'm looking at you random error logging format errors). Nothing. Nothing gets written to file at all. I don't have an error.

I then altered the case statement to write to file on warnings (error code >0). The file is written to and I'm getting a 1073676294 (bytes asked=bytes received). I then cleared that warning in case it was causing problems. It clears fine but the plugin is still causing problems in flexlogger. (yes, I did reboot flexlogger after build)

I then moved the process error writer to the end of Process.vi execution. No errors or warnings.

I disconnected the error wire from the Process terminal, nothing. I disconnect it from the Configure terminal, it works. (however, no error writing to file). I then altered the Configure error writer to report warnings. I'm getting another visa bytes asked=bytes read. So I'm guessing warnings cause this?

[JW-JnJ]

Another random note and question:

When I have a warning being generated in Configure (but not Process), I still get periodic errors in FlexLogger. Does flexlogger reconfigure the channel each time it updates?

It also is not allowing me to click run.

[Frisbee]

Hey Josh,

Sounds like that the warnings from your Configure Session.vi is putting the plugin in a bad state. If those warnings can be safely ignored, then I recommend scrubbing them at the source. I will spin up a test plugin and explore the warning vs. error behavior in the different states of the plugin.

FlexLogger should only run the Configure Session.vi either after Initialize.vi runs or if a configuration change has been detected. For example, changing your Frequency (Hz) plugin parameter would cause the Configure Session to run.  There is a good diagram and overview of the state machine in the FlexLogger Plugin Development Kit Manual (installs locally with the PDK too), see the FlexLogger Plugin LabVIEW Classes section.

If the plugin is in an error state before the test starts, then FlexLogger will disable the Start Test button to prevent a mis-configured system from running.

[Frisbee]

Hey Josh, 

I did some more investigation and confirmed what you were seeing.

If your Configure Session.vi throws a warning or an error, then you will not be able to start your test until it runs again without an error. For example, setting your COM Port parameter to something invalid could cause an error. Changing the COM port parameter will trigger Configure Session.vi to run again - and if it runs successfully then the FlexLogger test can start.

[JW-JnJ]

I removed the warning. However, even if I disconnect the error wire from both Process and Configure, it still disables the run button and the channel seems to disappear/reappear every second.

Nearest I can tell Configure is getting called once a second while idle. Right now I'm replacing the channel because I couldn't figure out how to change scale on an existing channel. I think I see that replacement happening in the UI.

[Frisbee]

Very interesting. Sounds like the plugin could be getting stuck in a configuration loop.

I have previously used the replace channel functionality with a plugin that modified the amount of producer channels based on how many analog inputs were mapped in. I will try out a few different test cases and see if I can reproduce the same behavior (without the need for your serial instrument 😉 )

[Frisbee · Accepted solution]

Hey Josh,

Replace Producer Channels.vi is indeed causing an endless reconfiguration loop. Replace Channel Group.vi has the same behavior. It was very easy to reproduce the behavior 🙂

I expect that both channel replacing VIs are unexpectedly queuing another execution of Configure Session.vi - leading to the endless reconfiguration loop in your plugin. This definitely feels like a bug to me, so I will get one filed.

Quick workaround: Add some conditional logic to not replace the channels if the units have not changed.