Leaderboard

Here is an article I read a while ago describing the ghost patterns, before reading it I always though the 4 ghosts just chased you randomly. http://gameinternals.com/post/2072558330/understanding-pac-man-ghost-behavior

Other than the error input/output, the functionality of the VIs didn't change. I'm not seeing an error when reading an entire file. I am seeing a *warning* 4 when specifying a number of rows to read greater than the size of the file, is that what you're referring to?

This is what I use. Would it do? RiseAndRunPanelVI.vi

Sure it is. Save and load it as a string and you can have any format you like. There is no date/time "type" in JSON!. Serializing dates to and from LabVIEW in a cross boundary way is, at best, a kludge and you always have edge cases (different separators, different offsets, different epochs.- the list goes on). If you view the date/time JSON object as a "helper" that tries the common types but specific ones you should just convert manually then there will be less bloat of the function as it trial and errors umpteen different formats and takes 10 hours to do so. You could even save the time and the format string along side it so you know how to re-interpret it. This cat has many skins. I never offer a date/time conversion in any toolkit for these reasons, but if I did, it would be a default conversion format with a string input to override with a custom one. That's my view, anyway.

If you have ever played Pac Man maybe you have noticed that each ghost has its own personality (i. e. Chasing technique) the base is common but they are choosing their target differently:that why I have made a different class for each one of them Inky s target is dependin also on Blinky s position. Ciao!

QUOTE (jdunham @ Nov 11 2008, 08:10 PM) Let me add a "me, too!" reply to this. Like others who have responded, I've written VISA serial code for countless devices (sometimes it's an instrument, sometimes it's the UUT) where the single-character termination simply does not apply. Invariably I end up with some sort of looping, scooping, bytes-at-port?/shift-register/string-appending/match-pattern/splitstring... ...you get the idea. All because the reply from the device has a two-char termination sequence, or some DLE-escaped format, or the checksum follows the term sequence, or the message starts with a length byte, or they use a CRC16, or any one of a dozen variations on the theme. I've long wished for a VISA extreme makeover that would include advanced pattern matching built in to the API. I don't have a clear vision for exactly how it would work, but I trust that those clever folks at NI would come up with something very useful...Until then, I just have fun writing drivers for the stuff nobody else wants to take on. Which isn't so bad. Dave