todd

Connectivitiy -> Input Device Control -> Initialize Mouse.vi and Acquire Input Data.vi.

It shows up as Button 4. Perhaps a separate loop that generates a dynamic event.

Do you have the report generation toolkit?

http://www.ni.com/analysis/excel.htm

or are you using ActiveX directly?

https://decibel.ni.com/content/docs/DOC-19913

I'm playing with "zero-coupled" AF components that are used by message handlers. The difficult part so far is managing the top-level actor in the "root" diagram (main.vi). Specifically, creating events or queues in main and passing them both to the control actor and to the message handlers.

Cross-post, here, with input from a company whi consults on SCORM:

http://forums.ni.com/t5/LabVIEW/how-to-make-labview-scorm-complaint/m-p/2174830/highlight/true#M699336

Probes and "Get LV Class Path.vi" have useful information about whether you're down-casting properly:

The period snuck in:

https://decibel.ni.com/content/docs/DOC-15560

You folks with your luxurious "written requirements" and "specifications"!

All my reqs and specs are transmitted verbally and telepathically.

Not a complaint - it's fun when the customer says, "Wow! I didn't think that could be done!"

Lapdog doesn't force you to really learn LVOOP.

Sorry, change the constant outside the sequence to True, then swap the cases for the sysexec.vi. Running that shows me the VI in the project (since I have a project open).

The snippet you posted sent key downs, but not key ups. Casting one of your clusters to a U8 array shows a different number of Bytes than the method in the zip file. You may need to adjust the representations, or pack the Bytes as in the zip file helpers.

I don't have 2012 on this box. However, I think sending an array of pInputs is too big. Try sending one keyup/down and one wVk at a time.

I found the guts of this dll call somewhere on the NI forums.

user32dll.zip

Edit: Oh, I sped through and missed your array indexing. Perhaps try the U8 data format in the zip file.

I have a MiniView GCS1804 KVMP (kvm and peripheral). It has a serial terminal, but I haven't tried to use that part.

Running that VI natively, here, it shows 0x18 - but it also performs the action (This VI in Project). I mentioned DirectX as the way that "Acquire Input Data.vi" probably works within the guest OS as a way for LV to see those inputs. The event structure probably ties in deeper than that. I imagine Parallels injects keys using a driver that is installed in the guest - or somehow uses "SendInput". Either way, it's a very tricky thing to manage. KeyOn and KeyOff need to be sent in such a way to avoid repeating keys, neglecting to send KeyOff can leave stuck keys, etc, etc. One of the Parallels threads mentions trying:

Virtual Machine -> Configure -> Options -> Advanced -> Optimize modifier keys for games. Oh, I have an old Parallels license around somewhere at home - maybe I can play with it tonight.

Short answer: I don't know.

That VI calls a LV function called getKeyboardState, which may be an abstraction of Microsoft's DirectInput API. If so, it returns a list of keys that are pressed. But that may be separate from the "Modifier Keys" bitfield in a keyboard report.

Just poking in the dark, here, and drawing a target that someone who knows better will hopefully shoot down

Perhaps Parallels isn't sending all of the HID Keyboard information to the guest OS.

One way to see may be to use System.Runtime.InteropServices.Marshal.ReadInt32().

I don't know it well enough to post code, though.

Happy to help. What's the first problem?

Motors manipulate devices. Instrumentation measures the devices. Different types of device data collection and different types of motor movements have different timespans and different requirements for synchronization. Currently, I use a left-to-right flow along with notifiers to synchronize things. I've been trying to figure out how to have the devices' drivers and the motors' drivers message each other. Is that vague enough?

I have been told by the obstetrician that they are identical!

Although I am not 100% sure what he based that finding on (I would have thought DNA would be the only test 100% conclusive).

Plus, it's a By-Val copy of an object with the ability to change its methods.

Are the results in each method repeatable?

Ha! I'm not sure if my contribution is just imaginary, or full-on negative.

Arg - I knew that applied to targets, but I didn't know it worked with projects.

Timing.

Nope, Adding an empty image will add one extra element in the multi column list box. This is not what I am looking for.

But 0 is still empty. You'll have to skip zero and start counting at one. (Add an Increment after the iteration terminal in the For Loop).

if you had read those 921600 bps with one VISA Read per received character it sure enough would have slowed you down

I used a separate loop to query "Bytes at Port" then read that many Bytes and put them one by one on a queue. (Termination character did not apply to that binary, streamed protocol.)

With the Windows com port at 921600, groups of between 500 Bytes and 4k Bytes are available as close together as 300ms.

With a VCP DLL at 921600, groups of between 100 Bytes and 3k Bytes are available as close together as 5ms.

So my guess is that the latency settings in the VCP allow for a "long" timeout (255ms before returning: "you expected n Bytes, but they did not all arrive"), and a short timeout of 2ms - which works well for the way I was using it (always reading available Bytes).

I forgot another point: I've used Windows-native com ports at 921600bps (with a full pipe). VISA r/w did not slow me down.

FTDI running at multiple Mbps slowed me down until the latency was adjusted.