Rolf Kalbermatter

QUOTE(TG @ Feb 3 2008, 10:35 PM)

I agree, in my exp there is a lot of eye glazing at NI when a significant Q is asked.

That does not happen here. Thats whay I joined in 2006 and never regret it.

Not just that. The average level of question is very basic on the NI forums in comparison with LAVA. And if you exclude the questions from a few very specific users on LAVA, you can consider the average level of almost every question to be professionel, and the answers as you say even more.

On LAVA I often do not post since I don't know the answer good enough to feel I can add something. On the NI forums I usually don't post since I don't feel any desire to spend even one second in answering a particular question and knowing there are many others that will eventually step up anyhow.

Rolf Kalbermatter

QUOTE(alukindo @ Feb 4 2008, 01:09 AM)

Your code shows that your column names include spaces, this makes SQL code prone to errors. For table names, you should use underscores symbol ( _ ) instead of spaces and then try again.

This assumes that you were able to succesfully connect to your ACCESS Database

Anthony

Or you can usually put the column identifiers into square brackets to allow the SQL parser to recognize them as one entity. But not using spaces in column names is actually good practice.

Rolf Kalbermatter

QUOTE(anima @ Feb 4 2008, 01:36 AM)

Actually I am using ADO tooltiks for Oracle database. It is taking a long time to read even a few data. The same is working fine with local database( MS access) . The server we are using for Oracle databse has no problem with the performance.

I would like to know if there is any constrain to work in LabVIEW with Oracle database.

Right now I am using LabVIEW 7.1. But the Tooltiks are of older version.

I was trying with the availble toolkits of LabVIEW 7.1, but facing some problem while coding.

If there is any suggestion from your side, please let me know.

What do you consider few data? And what is slow in that respect for you?

How do you query it, row by row or as a result set? If it is really simple (a single row for instance) or you query them as a result set then the problem must be in the Oracle connector that the ADO Toolkit connects to and you will have to look for support from some Oracle centric support channel. If your result has several rows and you are not already using the method to query the data as result set try that first.

When you say you tried with the Toolkits available for LabVIEW 7.1, what do you mean by that? The Database Toolkit from NI is at version 1.0.1 or something like that since a VERY long time and there was no specific release for LabVIEW 7.x or such.

How does your VI to query very few data look like? A picture of the diagram or (God beware) a little VI would say 1000 times more than what you have told us so far.

From the questions in this reply you do hopefully understand that the information you provide is still very minimalistic. Why do you think we should spend lots of our time to guess and second guess what your setup and specific implementation is, when you don't even take the time to sit down and consistently describe your problem as thorough as you possibly can? It is you after all that wants our help so doing some effort to get that help should not be to much asked.

Rolf Kalbermatter

QUOTE(anima @ Feb 1 2008, 09:49 AM)

Can any one plz suggest some solutions for this?

My crystal ball is out of order, so I can't see what you did and why you think it is slow. Just try to explain clearly and if possible show us some code. There is a lot one could do wrong but without having more specifics everyone here is simply dabbling in the dark.

Rolf Kalbermatter

QUOTE(vronto31 @ Jan 31 2008, 12:43 PM)

Hi

Can I connect Labview with SAP. If yes, is there some material or document I can use for help.

Thanks

Vronto

I haven't used it with SAP yet but another company wide database management system called BAAN. This used to be a rather popular system here in the Netherlands but is going to get replaced more and more by SAP it seems.

However BAAN was built on top of the Oracle database engine and therefore the Oracle ODBC access proofed perfect for what we needed.

Don't tell your IT guys that you are using LabVIEW, just ask them how to access their system from any client application through either ODBC or ADO. Once you know the specifics such as what ODBC/ADO driver to use and what parameters to use to connect and query the database you can just go about it much the same as you did with Acess.

Rolf Kalbermatter

QUOTE(Aitor Solar @ Feb 1 2008, 03:53 AM)

Anyway, I would prefer the type cast to try anything I connect, even if is not recommended.

I can only second that. It's an esoteric function enough that I would guess that people using it in such ways do know what they are doing and otherwise are prepared to live with the consequences.

I don't see a LabVIEW noob even knowing that it exists , let alone using it. As my workaround for the LuaVIEW Toolkit shows, treating the refnum as a 4 byte number and copying it into the 4 bytes of a strict typedef VI refnum still works correctly. So typecasting refnums at least in LabVIEW 8.5 is still simply a datatype change but does not change anything in the underlaying memory representation. I did assume that it might have been in preparation for more significant changes to the refnum system in LabVIEW in the future, that might break with simple typecasting.

But your idea that it might be more something about guaranteeing that a strict typedefed VI refnum points to something to be sure in memory might be also a good guess.

Rolf Kalbermatter

QUOTE(Aitor Solar @ Feb 1 2008, 02:34 AM)

I don't think so. In LV8.5 the type cast won't accept a strict VI refnum as the type definition, true, but we are talking about control references and those work well, also in 8.5.

Well, I see. It still might be a problem in the future, or the refusal to typecast to a strict typedefed VI refnum is maybe a bug?? Na, I don't think so.

Rolf Kalbermatter

QUOTE(R.Alves @ Jan 31 2008, 08:12 AM)

Hi there, thanks for the possible solution crelf, but the main purpose to adquire the video from the camera its to do processing video activities later, is this possible with your solution? Because i dont seem how could this be possible.

No for processing images later you would definitely need some image analysis library such as IMAQ Toolkit from NI or the IVision Toolkit from Hytek Automation.

Rolf Kalbermatter

QUOTE(souske @ Jan 31 2008, 10:21 AM)

Thanks for the reply.

As I wrote I'm using LabView Embedded Developmnet Module with some add-on that I found on ni.com that allows me to cross compile for QNX.

The standard C code node (I assume you mean Code Interface Node) is not supported by QNX target, at least that's what the error says:

"Code Interface Node: Node not supported in current target".

Right now I'm trying to use Call Library Function Node. I compiled the windows dll example for qnx (I used QNX Momentics) but I still get

some linking errors when I try to build it the project in LV:

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o: In function `sysexectest_BlockDiagram':

C:\tmpo\sysexec\QNX_Console\QNX_Application\sysexectest.o(.text+0x2b3): undefined reference to `avg_num'

cc: C:/QNX632/host/win32/x86/usr/bin/ntox86-ld caught signal 1

Any ideas what might cause the error?

No sorry. It's some time that a played with the LabVIEW Embedded Module, and that was with LabVIEW 7.1 too. Also I didn't incorporate any external code at all. Just played with the provided example framework for the Linksys WRT-54L router.

But no I didn't mean the Code Interface Node or CIN. As I have written many times here and in other places, CINs are legacy and NI is not going to go into any trouble to support CINs on newer platforms. They maintain them on the platforms where it is already working but for the rest CINs are dead. If and how the Call Library Node can work on your system is also a big question. If there is a clear and well defined standard for shared libraries on QNX it is quite possible that LabVIEW supports it. But I never went as far as using external shared libraries for LabVIEW Embedded so I'm not sure how they would support that. It looks likely to me that this would have to be part of the extra code one needs to write to interface LabVIEW Embedded with the external toolchain, but on the other hand I'm not sure how LabVIEW Embedded would provide hooks to do just that.

What I meant is that I think to remember that LabVIEW Embedded should have a C Code structure. It would sit on the diagram, look like a Formula Node and allow to type in C code that is then interfaced to the variables at the border. This C code will then be passed to the external C code compiler and of course could also contain calls to library functions present on the target system including your own shared libraries or object modules. I'm not fully sure that exists, never used it, but believe that I read once something about it. It is in that way much like the VHDL Structure for LabVIEW FPGA where you can write in VHDL code to be passed to the FPGA compiler.

Note: Ok I read on the NI site about it and it is called there the "Inline C Node".

Rolf Kalbermatter

QUOTE(souske @ Jan 31 2008, 04:32 AM)

Hi,

This problem is a mix of several smaller ones but I suppose the RT is the common ground here.

Most of the drivers for a given OS are developed and copiled under given OS. How to solve the problem of software (and driver) development on a computer

with a different OS than the target machine? For example software development in LV on Windows and execution on QNX OS?

I know that it is possible to use EDM mod (Microprocessor SDK) to compile for other OS and architectures (I've done that and it works).

But where do hardware drivers compiled for QNX fit in? Even if you use MHDDK (if I understand correctly) one compiles the driver (which is written in C)

on the machine with QNX OS. How am I able to use it in a software that I'm developing under Windows?

Including external code is limited. CIN and System Exec are not supported by qnx target and CLFN will probably join that group too (I'm checking it now).

Does any one has any suggestions how to bite this problem? Or maybe my approach is wrong?

Just to clarify. I develop software under Windows with LV8.2 and want to communicate with Hilscher Profibus card on a machine with QNX Neutrino 6.3.2.

How do you get your QNX system to work with LabVIEW? To my knowledge there is no direct support for QNX by NI other than possibly through LabVIEW Embedded.

If you use LabVIEW Embedded there should be the C code node (a bit similar to the Formula Node) that allows you to link to external code by writing calls to external libraries. Those libraries of course must have been created outside of LabVIEW with the toolchain for your target. How you do write these libraries and device drivers is entirely outside of the scope of LabVIEW. It does not care nor could it!

So for your main question you will have to take it up with the QNX support people for sure.

If you are not using LabVIEW embedded, the only way I see that your LabVIEW software could communicate with your QNX system would be a server application on the QNX system that access your Hilscher card and provides an RPC interface through TCP/IP for instance to your LabVIEW application. Only LabVIEW Embedded could possibly produce code that could directly run on your QNX target. But unless NI provides a ready made example for integrating LabVIEW Embedded with your specific hardware plattform and OS however (they obviously can't and won't create this for every possible target system out there), providing the necessary glue code to integrate your platform and OS into LabVIEW Embedded is a tedious job that takes up some serious time even if you are completely familiar with both your target plattform and LabVIEW Embedded (and if you are not, expect even a lot more time to be needed).

Rolf Kalbermatter

QUOTE(Harvey @ Jan 31 2008, 04:20 AM)

I use ADO--Toolkit for the connection between labview and database access.

But I have trouble converting dates read in labview data. because in every country the date is different

'1/30/2008 1:23:16 PM' Converted into '00:00 DD/MM/YYYY'

'30/01/2008 13.23.16' Converted into '13.23.16,000 30/01/2008'

There is a tool to determine date format in the operative system or ADO date format? Or automatic converter?

You sort of could write one, by converting a carefully selected timestamp into a string and then searching the specific positions and separation characters. The problem however is that this will never be able to solve all problems. This is because the DB engine and the according ODBC or ADO connector can or can not use the local date/time format on the machine they are running. I do know that the MS ODBC/ADO connector always observe the local format of the client machine and the SQL server can be configured to do that or not. Other SQL database engines will most likely have their own ideas about if and where to adhere to local format settings.

There is supposed to be an ODBC standard format for date strings, but I had at least with SQL Server trouble to get that working between different computers. The solution in that case was to use the SQL Server CONVERT() function in the SQL statements to tell it explicitedly the string format the date was in.

QUOTE

Same issue really. All MS ODBC/ADO client connectors will recognize the local decimal point. So for them you would use the standard LabVIEW formatting functions making sure "use local decimal format" is enabled in the Options, or using the Format Into String nodes add a %; to the beginning of the format string to tell it to use the local decimal fomat. Other database client libraries however may or may not observe the local decimal format.

Rolf Kalbemratter

QUOTE(R.Alves @ Jan 29 2008, 02:28 PM)

Hi there everyone, first i would liek to thank in advantage any help you people can provide me in this matter. Since i an a very amateur LabView user, didnt have any idea on which cameras are supported for labview use, so i bough a SVAT IP100 camera, that basically its a USB camera that brings a USB to Ethernet adaptor so in that way you can give an IP to the camera.

Along with the camera came a very basic software that gives you access to the camera using ActiveX or Sun Java, but it works through a web page basically.

I would like to know if anyone have any idea (a VI would be like a miracle to my prairs) of what should i need to do to access the video in Labview?

I-ve tried all the, UDP, and TCP/IP options along with Labview 8.2, but i've heard that since its an ethernet protocol, i need to extract from the coomunciation only the video information that are together with some acknowlegdes and other stuff along with ethernet protocol, and ad this moment i have no idea of how to do that.

Again thanks for the help i can get in this matter, hope to hear soon from you guys.

Regards,

R. Alves

Duplicate post! Look http://forums.lavag.org/Package-for-Ip-cameras-t10006.html' target="_blank">here.

Rolf Kalbermatter

QUOTE(Neville D @ Jan 30 2008, 03:49 PM)

For windows only, not yet for LV-RT. It has been on their "to-do" list for more than a year now.

Neville.

Which RT system has a GigE interface? Without it won't work anyhow.

Rolf Kalbermatter

It's considered polite to put up a link for cross posts.

Here is the same text again.

It seems not possible to find any detailed specs for this camera on the internet. That means I can not even guess how to access them at all.

But since it has a built in web server you can always access the images through HTTP. This could be either done through a IE ActiveX control or similar embedded in your VI front panel or by using the Internet Toolkit HTTP VIs to retrieve the image programmatically. OpenG has some rudimentary HTTP routines too, which should probably just work fine too.

Rolf Kalbermatter

QUOTE(TobyD @ Jan 29 2008, 02:55 PM)

That's exactly what I thought! It must either be the same person, or they have the same professor. :gathering:

And if the first is true I wonder if the name is just to try to get more likely help as a HH :laugh:

Rolf Kalbermatter

QUOTE(R.Alves @ Jan 29 2008, 02:37 PM)

Would be great to count with a package like the IMAQ package but for use with IP cameras, where all the process of capturing the video information of the communication protocol would not be an issue to the user.

Well, nice idea but there is a problem with that. There is nothing like a single IP camera communication protocol that I'm aware of. If a camera has the possibility to be controlled over IP directly it is sometimes RSTP or a proprietary protocol, that you can access through an Active X control only, and whose protocol is not normally documented or it contains an embedded web server that can be accessed through a web browser. For the proprietary protocol through ActiveX, you would have to integrate it through use of the Active X functionality in LabVIEW and this will be of course camera specific, and the second you could access trough the HTTP VIs that are part of the Internet Toolkit and of course are camera specific too, since the web server structure is also different on each camera type and sometimes varies between versions of the same camera too.

RSTP is not very common and only really allows control of the camera itself, but is not the streaming protocol itself. If the camera supports it you can request with the DESCRIBE command an url from which you can retrieve the current image, which will be usually an FTP or HTTP url, and that can be handled with the Internet Toolkit.

But considering the NON-standardization among IP cameras such a Toolkit will never be able to support more than a few specific cameras, so it will be hard to justify creating something like that unless you happen to have a specific application, and that means often that one develops them for a specific project and therefore can't just put it up for free download because of right of ownership.

There is of course also GigE, which is a standard and I think NI is supporting that already.

Rolf Kalbermatter

QUOTE(Tim_S @ Jan 28 2008, 07:53 PM)

You could open the file and use "Read from Text File" to read n number of lines. You'll have to right-click on the primative function and check Read Lines to do this. The Spreadsheet String to Array primative would also be useful.

Tim

Why do sara and jennifer post quite similar requests here. I get this feeling that sara learned from the reactions and now got an identity change and tries to at least show that she did a little work before asking questions. Still!!

Rolf Kalbermatter

QUOTE(Yen @ Jan 29 2008, 01:23 PM)

I don't use IMAQ, so I don't know if this applies, but for some reason you can't do Customize and then another one on a subcontrol. Try selecting File>>New>>Custom Control, dropping an IMAQ image in the control editing window and then customizing. Can't guarantee it will work, but it should be worth a try.

It won't! The IMAQ Control is not really a fully built in Control but added to the LabVIEW system as an extra through external files. Those external controls do not support the object methods necessary to edit the control.

And you can customize sub controls of normal built-in controls! You can't open a customize window for a second control when one is already open, but when there are editable sub controls (such as a digital control in a slider for instance) you can open that in a second editor window.

I know from the original creator of the Control Editor that he considers that as a work that was done back at that time which should have been redisiged since a long time. One limitation was that that editor was not really reentrant for instance which made it necessary to disallow multiple editor windows being opened at the same time, except for the case of editing sub controls. Another limitation is that it is fragile at its best. Unexpected edit operations or controls that behave strange in some circumstances can make it go complete belly up together with LabVIEW and all your code.

Rolf Kalbermatter

QUOTE(Yuri33 @ Jan 28 2008, 05:28 PM)

Is this confirmed to work? You can simply typecast a generic control reference to a strictly typed reference? Will this work at run-time (in LV8.2)?. I would love to change my application back to the way I originally had it (and slay the last global!), but I don't want to put the time in if I'm going to run into the error again at run-time.

It works in LabVIEW up to 8.2.1 but fails in LabVIEW 8.5. The typecast function will refuse a refnum connected to it with a broken wire. We found this in our LuaVIEW Toolkit package and had to develop a workaround for it. I sort of understand the idea behind, since a refnum is in fact something like a pointer to an object and messing with pointers can be a VERY bad thing.

There is a chance that that new behaviour in LabVIEW 8.5 is in preparation of something that might change the refnum entirely and that might make the workaround we developed for LuaVIEW in LabVIEW 8.5 invalid again in a future LabVIEW version.

Rolf Kalbermatter

QUOTE(PeterB @ Jan 28 2008, 05:43 AM)

Does this mean that if a User Event is fired there could be times when it won't be serviced "as fast" as the enqueue/dequeue method ? If so, is that because the Event Structure may have previously switched to the UI thread before switching back to another (non UI) thread in order to service the User Event ?

Peter

It means that the event structure might be serving an UI event at the moment the user event arrives and hence not be able to react immediately. A Read Queue waiting for an event to arrive will return instantly or at least as fast as possible, considering the contstraints of available CPU power and load only.

Rolf Kalbemratter

QUOTE(macbeth @ Jan 21 2008, 03:52 PM)

I just ran across the same problem.

I have a VI with 4 waveform graphs and I can't get it to print out. i only get white graphs with no data (plots) in it.

The strange thing about it is this:

I have tried LV8.0 (Windows), LV8.2 (Linux) and LB8.2 (Windows), on three different boxes with exactly the same result.

Now if copy all front panel elements and copy them to a new VI (with all the data in the graphs) I can print them without problems.

I have never seen this behaviour before and I have absolutely no idea how I can make it work!

Why not show your VIs?

Rolf Kalbermatter

QUOTE(crelf @ Jan 17 2008, 08:36 AM)

I can't say for sure, but maybe the check is applied to any version below the current one (?) So you should be able to create a new VI in 8.2 with a constant feeding a case structure, then open it in 8.5 and have it convert - but why? If you've got a constant feeding a case structure in 8.2 then it's going to act the same way as in 8.5. Intriguing - is anyone with 8.5 able to try it? I've attached an 8.2 example VI.

This dialog should only be triggered when upgrading a pre 8.0 VI. So I'm afraid it is probably more a question of a corrupted VI somehow. For some reasons LabVIEW 8.5 does believe it is a pre 8.0 VI and applies that check but then stumbles over something else that is inconsistent in respect to this assumption.

A bug? Well strictly speaking the bug happened either when saving that VI in 8.2 or the VI was corrupted somehow in such a way that 8.2 did not have trouble to read it but 8.5 has. It would be of course fine if LabVIEW 8.5 would just inform you of the inconsistency and continue instead of hanging, but there are miriads of things that can be inconsistent and anticipating them all is not very easy and checking them all is even less practical.

I do think that technical support would be interested in this VI to be attached to the CAR so that LabVIEW development may look into the kind of corruption and maybe apply an extra check in the VI loader.

Rolf Kalbermatter

QUOTE(silmaril @ Jan 10 2008, 08:26 AM)

Thanks for those hints!

I played around with the ini settings, but I didn't succeed in solving this problem. I seems that I am able to define a larger font size, which makes the plot legend larger, but I couldn't get a smaller size.

The 2nd possibility worked fine. I changed the font of the plot legend to "Tahoma 13" and it was identical in the development environment and built application.

I still think this is a bug in LV!

The Application Font changes with the Windows settings. This happens both in the development environment (after you restart LV) and in the runtime engine. I don't see any reason why this should look any different on the same computer with (of course) the same Windows configuration.

But even if this worked correctly, it still was a good idea to set the font independently from the Windows settings if you need to be shure that there is a checkbox next to each plot name.

Edit: I forgot to mention the CAR number: CAR 4H921LN3.

It may be that you have fiddled with the default fonts in your development environment. Check your LabVIEW ini file for entries like FPFont=, BDFont=, AppFont=, DlgFont= etc. When you change the font settings while you have some control or text setting selected the change applies to that control or text. Without anything selected the change applies globally and will also be written to the INI file if it is not the default setting.

An application has its own INI file and by default no Font settings are in there which will cause LabVIEW to use default Font settings. The LabVIEW 8.5 Application Builder does copy some of the INI settings from LabVIEW.ini into an application specific INI File unless you disable that by specifying your own INI file in the build. But I'm not sure if Fonts happen to be among them, as I almost always use customer specific Font settings for Buiild applications.

So no, I'm sure it is not a bug, but yes I do think the Font settings and default Font configuration could use some extra explanation somewhere in a prominent spot in the online help. And the Font configuration dialog could be more intuitive. The checkboxes for Panel Default and Daigramm Default are a bit hard to understand in respect to how they influence the INI file and future changes to a VI.

Rolf Kalbermatter

QUOTE(ben5248 @ Jan 24 2008, 07:53 AM)

All NI compactRIO modules come with the model number listed at the top of the front panel in blue.

Some are labeled "NI cRIO-XXXX" while others are labelled "NI XXXX". Is there a difference in functionality?

For example I have seen NI's IEPE module labeld both "NI cRIO-9233" and "NI 9233".

Probably just a change in marketing. Those modules were introduced with cRIO but in the meantime are also usable with the new USBDAQ modules NI sells. So I guess they decided to drop the cRIO in the labeling to not confuse users.

Rolf Kalbermatter

QUOTE(ashwin @ Jan 27 2008, 04:56 AM)

Anybody coming up on this please?

I think we can use messaging queues for this along with dynamic events? want a more focused example?

Forget the queues for a moment. You want to call those DLL functions in a loop or something and test it's return value or it's returned parameter until it gives you the value to tell you it is ready. Then you call the function to retrieve the data or do whatever else you want to do.

There is no way to use LabVIEW queues or such directly with the DLL. Once you have the DLL calls working properly you can of course develop a VI library that could give you a queue based interface. But I do not think that would have real advantages over a more direct VI library approach directly.

Rolf Kalbermatter