Leaderboard

While I have received no replies to my question, I have made some progress. The correct sequence of DLL calls has enabled me to exercise control of the processor through the Background Debug Mode (BDM) Port, using the Call Library Function Node in LabVIEW. I'll outine my progress, in case someone else out in the LabVIEW universe is trying this. The PE Micro DLL must first be loaded into memory, and remain in memory for subsequent calls, which requires dynamic loading of the DLL. Dynamically loading the DLL is accomplished by setting up the Call Library Function Node to specify the path to the DLL on the diagram of the calling vi. Right-click on the Call Library Function Node, and select Configure. Check the "Specify path on diagram" checkbox on the "Function" tab, and click on OK. There will now be a path input to the Call Library Function Node. Wire a constant or control to the path input that points to the DLL. That took care of the dynamic loading of the DLL. Be sure to include logic in the vi that loads the DLL that will also enable it to unload the DLL, which must be accomplished in the same vi that loads the DLL. Unloading is accomplished by wiring a blank or empty path constant to the path input of the Call Library Function Node. A simple select function allows you to either load or unload the DLL by hooking the path to the DLL on one input, and an empty path to the other, and have the output of the select function feed the path input to the Call Library Function Node. Then a simple boolean control can be used to select whether the vi loads, or unloads the DLL. Once the DLL was loaded, I still had to determine the proper sequence to get the PE Micro Multilink Interface to actually talk to the MPC850 processor on the circuit board. The sequence of calls to functions within the DLL that I used is listed below: reenumerate_all_port_types get_enumerated_number_of_ports (The Port Type input to this would be "3", as that is the designation of the USB Multilink Interface.) open_port (Port type is 3, port num is 1) reset_hardware_interface Once I had this sequence worked out, I was able to start reading from and writing to memory and register locations with the other functions in the DLL, which, so far, has opened up a lot of the processor and circuit board for testing. I hope someone else finds this information useful. Dan

Sending things to the controller is fine, but if all the Plotter does is plot raw Hardware data, then what are you gaining by splitting them? If it’s more than that; if Plotter is more than just a straight UI for Hardware, then it makes sense. Personally, I would always start with a “Hardware” actor running by itself, for initial debugging in isolation. For that, Hardware needs a UI (preferably simple, low-overhead, and one that has no overhead if Hardwares Front Panel isn’t loaded). Often this UI can serve as a part of the application UI by being in a subpanel. Ask yourself this: if you reused Hardware in a new application, would you reuse Plotter as is? If so, maybe it would be simpler to combine them. If thing’s got worse when you reduced the UI update rate then you did it wrong. No. Though you can do the equivalent thing with messages by having them flag the need for a UI update, but not do the update till later (after many messages have arrived. Do you batch signals? Or send a separate 30+ messages/sec for each of 50 signals? 30 messages per second containing all signals can’t have THAT much overhead. Oh, BTW, make sure your not using “Build Array” anywhere as that can be slow.

That has got to be among the most subtle settings I've (n)ever seen! I thought it might be new, but it was there in LV 8.6 as well! I am very dissapointed in myself for missing that So, we can use the native Format into String and Scan from String functions with a single format specifier string to create and convert a timestamp to an ISO-8601 UTC compliant string. Please excuse me now while I search eBay for a slightly used tantō...

After a few dark side and twitter posts cursing date and time formatting, I have to say I STRONGLY support using ISO 8601 compliant strings. Be aware that the format specifiers for the "Format Date/Time" primitive are NOT always interchangeable with ISO 8601. I posted an ISO-8601 example on the dark side that supports extended and basic formats as well as ordinal dates. https://decibel.ni.c...t/docs/DOC-7199 I've attached a copy here. 8601 UTC Date-Time String.vi