G#

cancel
Showing results for 
Search instead for 
Did you mean: 

Supported for LV Real Time?

Hi all, i'm really keen on porting my code to G# classes as i really like the object reference that LV object doesn't support. However some of the Classes i had are deployed to compactRIO. I wonder if G# is supported for LV real time?

Many thanks!!!

0 Kudos
Message 1 of 10
(8,045 Views)

Hi,

Yes, G# supports RT. It has been tested on RT and I've had an G# application running for many months on a LV RT target. You can't create classes directly on your RT target in the project, but have to create them locally and then you could use them on the RT target. Notice that there also exists a G# Debug Server that could be used on the RT target that you could use to probe the objects and states on the target. In your RT application, include the G# StartDebugServer.vi (G# advance menu) as the first VI in your RT application and the G#GarbageCollector.vi as the last VI on the diagram (this will stop the debug server). The G# Debug Server will listen to all G# events and the G# Debugger will remotely through TCP/IP connect to the the G# Debug Server. The picture below shows a very simple RT application using the G# Debug Server.

G#RT.jpg

Now launch the G# Debugger in your RT project (or any other project or machine). There is a button on the first tab called "Connect". Press this and a connection dialog should appear. If the RT target isn't listed (or has an IP 0.0.0.0) then you could specify the IP-address manually as shown below.

G#DebuggerConnect.jpg

Now all your RT objects should be visible with a prefix showing the IP-address and the trace should also be showing all G# events, just as if you are running on a local machine. It could take a few seconds before everything is setup correctly. Notice that the object state doesn't show the same object attribute type def control as on a local machine, if the classes that are debugged on the remote target aren't present in the local project scope on the machine running the debugger, these object states will be shown as text instead.

G#DebuggerRemote.jpg

The G# Debug Server could be used to remotely debug other applications as well such as executables and web services. I use it heavily debugging web services.

Thanks,

Mattias

Message 2 of 10
(6,055 Views)

It could be important to mention that the G# Debug server deployed on the RT system does not affect the system until a G# Debugger session connects to the server. Hence no process load (or minimal) is added until a client access the server.

Message 3 of 10
(6,055 Views)

Thanks for all the replies. However i wasn't sure about this statement.

"You can't create classes directly on your RT target in the project, but have to create them locally and then you could use them on the RT target"

How can i go about this of creating it locally and then use it on RT target?

0 Kudos
Message 4 of 10
(6,055 Views)

Hi again,

Sorry for the confusion regarding "Create". What I meant is that you must generate the class by right-clicking on "My Computer" and select "Create G# Class" when creating the code, the option doesn't exist if you right-click on the target and tries to generate the class code directly to the target. I had some problems with scripting when trying to do that. Then you just use the G# LabVIEW code as any LabVIEW code on the RT target.

You could then of course use the G# class in your RT LabVIEW code and the create objects on the targets. Would be quite strange else! In the RT example code above, you can see that I create an object on the RT target and then destroys it at the end. In this example, the timed loop actually will create and destroy objects over and over again. I used it as a test when verifying G# on RT.

Once again, sorrry for the confusion. It is some difference between creating code and creating object...

Mattias

0 Kudos
Message 5 of 10
(6,055 Views)

Thanks for the clarification. My intention was to create a library (lvlib) locally in a project and build it as a packed library which will be used on other projects.

0 Kudos
Message 6 of 10
(6,055 Views)

I belive that packed libraries are only supported in the version of LabVIEW of where it was built, if you plan on using the packed libraries over a period of several LabVIEW versions it could be a problem. Just a hint.....

0 Kudos
Message 7 of 10
(6,055 Views)

Thanks for the hint. So what would u suggest if i wanted to relase my lib for different projects and LV version.

0 Kudos
Message 8 of 10
(6,055 Views)

Hi,

Well, you just have to rebuild your packed library if you change LabVIEW version or OS. That's simply how they work, nothing really to do with G#. Guess that is the issue with the packed libraries, but not a big problem if you keep a copy of your source code...

Mattias

0 Kudos
Message 9 of 10
(6,055 Views)

So true, it's more an issue depending on the scope of the libraries, if they are to be used widely and in several plattforms...then it is more a maintinance problem i guess.

0 Kudos
Message 10 of 10
(6,055 Views)