Jump to content

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


smarlow

Recommended Posts

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.

Link to comment

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.

Link to comment

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?

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment
  • 4 months later...
  • 6 months later...
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?

Link to comment
  • 9 months later...

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!

Link to comment

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!

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.