Additional NI Software Idea Exchange

After running a compilation, the Functional Safety Editor produces several files, including the actual bin file for uploading to the 935x module, plus a compilation report and other compilation results. The FSE manual recommends reviewing these output files for correctness.

Problem is there's no quick way to open these files for review. So I think it'd be useful to provide a button to open File Explorer to the folder containing the files produced by the compilation.

LabVIEW has a nice feature allowing an arrow to be drawn from a comment and attached to a block diagram element. This makes commenting specific parts of code much more precise. The Functional Safety Editor lacks this feature (and is inefficient to comment in general). When adding verbose comments to the diagram, it can be unclear which comment belongs to which state or transition.

The proposed idea is to add the same comment/arrow functionality from LabVIEW to the FSE, so comments can be attached to a transition, state, compound state, etc.

Comments can be added to the diagram in the Functional Safety Editor, but only when dragged from the palette. It's second nature in LabVIEW to simply double-click a blank area of the block diagram and begin typing to add a comment, so the lack of this feature in the FSE is really jarring.

This idea is to enable double-clicking an empty area of the diagram to automatically insert a comment, without the need to drag it in from the palette.

The Functional Safety Editor lacks a pan tool for navigating the diagram view. The only option is to use the scrollbars + mousewheel.

This proposal is to add a pan tool, activated by a keyboard+mouse shortcut. This could be Ctrl+Shift+Click (like LabVIEW) or Space+Click (like NXG). This would make navigating the diagrams of larger safety programs much quicker.

Currently the Functional Safety Editor file dialog always defaults to the path %userprofile%\Documents\LabVIEW Projects\Functional Safety Programs when opening or saving user programs. This is regardless of where the user program was opened from, or where the program was last saved to. This is unlike LabVIEW, where it will always remember the last used directory and use that as the starting path for file saving/loading.

The default file dialog path for the FSE can at least be changed in %localappdata%\National Instruments\Functional Safety State Machine Editor 6.0\Preferences.xml (under the key NationalInstruments.Shell.ApplicationFeatureSetDefaultDialogDirectory) to a more sensible default path (the root of your preferred version control system). Even so, it is still tedious needing to change folder paths to a given project for every save or load operation.

A better UX would be to remember the last used file path, and use that as the starting path for any file open or save dialogs. Much less clicking and navigating required.

(Labelled this as System Configuration API, but the FSE is its own product)

LabVIEW provides access to a list of recently opened Projects and Files, which is handy for quickly resuming where you left off. The Functional Safety Editor lacks this feature. Combined with the default file dialog issue, it makes reopening user programs a time consuming exercise.

The idea is to add a Recent User Programs menu item to the File menu, listing the last 10 or so user programs (just like LabVIEW).

(Labelled this as System Configuration API, but the FSE is its own product)

強制ドットは意図的でないデータ型式の変換を警告するが、データ形式が同じでもタイプ定義の有り無しが異なると強制ドットが付く。

これは疑似エラーであり、データ形式が異なる真性エラーをマスクしてしまい、強制ドット警告の品質を劣化させている。

従って単にタイプ定義有り無しの違いに対しては強制ドットの色をオレンジ色にするなどしてエラーレベルを落とす方が良いと思います。

また、ブロックダイアグラム中の強制ドットの検索方法が提案されているが、強制ドットは常にバックグラウンドで検索して欲しい。ちなみにプログラム実行に支障が有るときは実行指示のボタンの形が変わり実行出来なくなるが、強制ドットなどがある場合にはボタンの色が変わり、右クリックなどで警告の一覧表が出て、それぞれを確認できる仕組みが欲しい。

特にタイプ定義を使っているとタイプ定義の修正の結果、意図しない場所で、新たな警告が誕生する可能性があり、毎回意図的に強制ドットの探索を掛けるのは非常に煩わしく、失念する要因となる。前記の機能があれば、修正直後に副作用を確認できる。

Hi,

For a reason I don't know, NI Softmotion team remove the function "write position setpoint" to all 951x axis. I'm using four (4) 9514 axis right now that all need to use this function at sometime in my code.

This function is really useful when design a motion tracking system and also for PID tuning to check step response.

I can't upgrade to LabVIEW 2018 for this reason without non-desired work-around.

Please work on reenabling this fonction on all 951x axis.

Is there a technical reason why DAQmx Scales can't be added to VeriStand waveform channels?  My understanding is that the logging mechanism is just the shipping NI-DAQmx Configure Logging function, which supports logging channels with applied DAQmx scales.  I'd like to see the same right click menu "Select Scale" option that you have for single point channels to enable it.

Right now I'm looking into how to apply these scales.  It looks like I could either add a custom device or post-process the TDMS file, neither of which is a terribly elegant solution, especially since what I'm trying to enable is a shipping feature of the underlying driver and would be annoying to have to replicate.