LabVIEW EXE Running on a $139 quad-core 8" Asus Vivotab tablet

[smarlow]

Hello everybody.  I just wanted to show LabVIEW running on an Asus Vivotab 8 tablet.  The tablet was purchased in a good deal for $139 (now gone), but can be purchased from Microsoft for $149.  It runs the Intel Atom Z3745 "Bay Trail" quad-core cpu, has 2GB of ram (most other value tablets only have 1GB ram), and 32GB of flash, plus a micro SD slot and USB OTG.  The unit I purchased came loaded with Win 8.1, but I believe the units being sold by MS come with Win 10 preloaded. I downloaded the LabVIEW 2014 SP1 runtime engine directly to the tablet and installed it with no issues.  I then updated the tablet to Windows 10.   I used my Win 7 pro laptop to create a simple application that throws some white noise into a waveform graph and compiled it to an executable.  I transferred the application to the Vivotab 8 using a micro SD card, and ran the app directly from the SD card. It runs LabVIEW runtime like a champ.  Very fast loading (although it is a simple app) and fast screen updates, virtually no difference from my laptop.  So if you want a great tablet that will run LabVIEW for around $150, this puppy will do it.

 

Shouldn't there be a forum category devoted to LabVIEW on tablet & phones?  There is a PDA category, but that seems a bit dated.

[Darren]

Thanks for the rec. I've been looking for a cheap tablet to run LabVIEW apps on, this one looks like it will fit the bill, so I snagged one from the online microsoft store.

[hooovahh]

Pretty neat, thanks.  As for your forum comment.  How are the applications running on these targets different than the majority of LabVIEW applications running on Windows?  If there is a need for a separate discussion subforum for targets like these, I can talk to the powers that be, about making a separate subforum.  But the way I see it these are just normal Windows targets running normal EXEs.  The only discussion about them I could see is about the hardware selection which can really take place anywhere, even the LAVA Lounge would be appropriate.

[smarlow]

Hooovahh: I get your point.  There are issues unique to these devices, such as DAQ hardware, horsepower, etc.  I guess I was just a bit unsure about where to post this thread, and had the thought of a dedicated category.

[hooovahh]

Fair enough.  I think people worry too much about a proper category.  Generally the only time a move is requested is when the category has nothing to do with the subforum.  And in those cases it takes like 5 seconds to move a post to another section.

 

I guess speaking of performance, I'd expect any normal USB DAQ, or DMM to work with this hardware.  In a pinch I've used a myDAQ for a DMM and basic scope.  Having one of these tablets be the front end could be handy.  I'd much rather have a Virtual Bench, if say maybe the cost were half what it currently is.

[mje]

Cool. I'm most interested in how people find interacting with LabVIEW via a touch interface. I do a lot of hack-ish UI work in some of my applications which I wouldn't expect to translate too well, but I'd hope the native stuff would be pretty straightforward?

[smarlow]

I put an enum on the front panel to see how it would respond, and it seems to work fine.  I have actually worked with LabVIEW and touch screens quite a bit in the past.  I have done automation apps in which LabVIEW was used to program the touchscreen MMI.  To make the job easier, I created a bunch of custom controls with oversized inc/dec controls, large font text, etc., and my own VI-based onscreen keyboard controlled with mouse events.  Of course the on-screen keyboard in windows has improved since then (the old XP OSK was not resizable, and the keys were too small to use with fingers on a touch panel).  

 

One of the problems I've noticed with the Windows touch keyboard is that it does not re-position the application on the screen to keep the field of entry visible above the keyboard, so you can't see what you are typing if the field is at the bottom of the screen.  My android tablet, and kids' iPad always keeps the field in view automatically.  Windows also does not bring up the keyboard automatically when cursor is placed into an entry field, even in their own browser.  You have to touch a button on the task bar.  Perhaps this is a setting.  Being a Win 7 user who refused to upgrade previously, I am not used to Win 8.1 or 10.  I suppose I should Google it.

[ShaunR]

Being a Win 7 user who refused to upgrade previously

Watch out for the backporting updates for the Windows 10 spyware telemetry!

[hooovahh]

Cool. I'm most interested in how people find interacting with LabVIEW via a touch interface. I do a lot of hack-ish UI work in some of my applications which I wouldn't expect to translate too well, but I'd hope the native stuff would be pretty straightforward?

Yeah I think the same thing.  Really it doesn't matter the language, but if a program was developed with a mouse and keyboard in mind, it probably doesn't work well on a touch screen.

 

If I knew I'd be targeting a touch screen, I would probably need a different set of hack-ish UI tools.  The first change that comes to mind is how right clicking would probably never be used.  Or if it was a custom popup would be needed.  There probably wouldn't be a menu bar, or if there was it would be replaced with custom large icons.  And I imagine there would be more drag and drop, as well as larger controls.

[ssingh1]

Thanks for the nice information.

 

Any Idea, if we can we attach a 16 Bit, 16 Channel USB DAQ Card to it for Data Acquisition?

Edited September 13, 2015 by ssingh1

[hooovahh]

It's hard to say for sure, but based on the performance I'd say some DAQ work shouldn't be a problem.  I'd guess you'd see significant performance issues if you tried taking something like N channels N samples at a very high rate, and then try to post process the data.  But this might be fine for say a log to TDMS and then display a subset of data.  

 

A quad core atom isn't nothing to sneeze at.  In the past I actually deployed a test system that ran on a dual core atom, running Windows XP.  It had a couple ethernet based cDAQ systems performing a sequence of events for controlling solenoids, and measuring mass flow.  Ultimately it was used to measure the efficiency of semi-truck air dryers.  We went with this PC because it was pretty small.  It had room for one PCI slot and was passively cooled, it was just a big heat sink that we could put in the cabinet with all the equipment.  We just attached a monitor on an arm and didn't need the whole second cabinet we were replacing.

[ssingh1]

It's hard to say for sure, but based on the performance I'd say some DAQ work shouldn't be a problem.  I'd guess you'd see significant performance issues if you tried taking something like N channels N samples at a very high rate, and then try to post process the data.  But this might be fine for say a log to TDMS and then display a subset of data.  

 

A quad core atom isn't nothing to sneeze at.  In the past I actually deployed a test system that ran on a dual core atom, running Windows XP.  It had a couple ethernet based cDAQ systems performing a sequence of events for controlling solenoids, and measuring mass flow.  Ultimately it was used to measure the efficiency of semi-truck air dryers.  We went with this PC because it was pretty small.  It had room for one PCI slot and was passively cooled, it was just a big heat sink that we could put in the cabinet with all the equipment.  We just attached a monitor on an arm and didn't need the whole second cabinet we were replacing.

 

Thanks for the detailed reply.  We too have successfully used Industrial PCs having Single Core Atoms (D425) and Duel Core Atoms (D525) for our LabView Applications in the past even on Windows 7. We have used both PCI and USB Cards for the purpose as the need arises. We only faced problem once when we tried to use two PCI Cards Simultaneously using a PCI Raiser Card which resulted in a resource conflict.

 

My main concern was that if the Tablet PC will be able to drive the USB DAQ Card and keep up with the required data transfer rates of data acquisition as in the Industrial Atom PCs. If that is possible then it seems to be a Great idea for us and many more people like us especially as there seem to more such products coming soon like one given below :-

 

http://www.micromaxinfo.com/laptab/canvas-laptab-lt-666/?utm_source=MMX-Tablet-GoogleS-Always-On&utm_medium=CPC&utm_campaign=GoogleS-CPC-Laptab-Brand-Product&gclid=Cj0KEQjwg9-vBRCK7L7wmO2u0JcBEiQA_tzoaK1bqYncinBXdf3BuFzFoYfKD9OTtDyPcbIcj7DlCjEaAlGI8P8HAQ

[hooovahh]

My main concern was that if the Tablet PC will be able to drive the USB DAQ Card and keep up with the required data transfer rates of data acquisition as in the Industrial Atom PCs. 

I can't say for certain what the limitation would be, only that when we were developing applications on the dual core atom we had at times a USB cDAQ or at times an ethernet based cDAQ which would do finite DAQ sampling, but primarily single point stuff.  It was a pretty slow system, and really just need to check signals once in a while and turn on solenoids once we reached a certain flow/pressure.  My point is we didn't push the limits of data transfer.

[JoeQ]

How is the tablet holding up.   I tried running LV on one.   It can read the tablets GPS sensor but everything else comes from the USB.   

 

https://www.youtube.com/watch?v=6PpAJeAurr4

Edited January 29, 2016 by JoeQ

[BJKluft]

On 9/10/2015 at 0:52 PM, smarlow said:

One of the problems I've noticed with the Windows touch keyboard is that it does not re-position the application on the screen to keep the field of entry visible above the keyboard, so you can't see what you are typing if the field is at the bottom of the screen.  My android tablet, and kids' iPad always keeps the field in view automatically.  Windows also does not bring up the keyboard automatically when cursor is placed into an entry field, even in their own browser.  You have to touch a button on the task bar.  Perhaps this is a setting.  Being a Win 7 user who refused to upgrade previously, I am not used to Win 8.1 or 10.  I suppose I should Google it.

I have the same problems as mentioned above. Does anybody have a solution for this?

[JIbb]

I am using an Asus Vivotab and running a LV executable program.  The program has buttons that need to be selected by the user and on a normal laptop the button responds with a single mouseclick.  On the Vivotab a double tap or double mouseclick is necessary.  Does anyone have any ideas on how to get the button to respond to a single tap/click?  I have tried to change the settings on the Vivotab without any luck.

Thank-you for any help!

[JIbb]

It seems like it depends on how the mouse click is detected within labview - on the desktop a property node of mouse information can be used to detect a button down action but this does not register on the vivotab unless a double tap occurs.  I think I will try using an event structure and a mouse down event.  This looks like it might work if I can figure out how to incorporate it into my existing program.  Does anyone have any ideas why the property node button down wouldn't register?

Thank-you!

[hooovahh]

You should be using an event structure.  If you use an event structure you can register for mouse down, mouse up, etc, or on value change.  Then the event will be triggered on that event instead of polling a property node which forces a thread swap to the UI.  Post your code if you can.