Mark Balla

I wish the ability to automatically remove the previous source of a wire when I connect a new source. It could be controlled by holding a control key when wiring or settable as the default behavior.

5043[/snapback]

A BIG second on this Idea.

I use the delete button so often that I made it one of my programable buttons on my mouse.

Have you submitted this to NI?

Here you go.

Here is a Demo program that shows how I would approach this program.

First separating the User interface from the Processes by using separate loops

Next Use a state machine to separate out each process and Daq event.

Finally tranfer commands between the 2 loops by using a Que.

Download File:post-584-1117644639.llb

Hope this isn't too far over your head.

This is my favorite type of structure and I use it in various forms for all of my programs.

First make sure that that you are using Waveform Charts not Graphs.

Graphs will only accept arrays or special clusters.

Try this code to pull the data out of the subvi.

Download File:post-584-1117597826.llb

I would only do this if the subvi acquiring the data is slow >200 ms per reading.

The reference method is useful for this type of application but it is not recommended

for acquiring data fast.

Here is how you would do it using the event structure.

Select Vi with the mouse up option

Wire off of the button terminal for start or stop.

The mouse cursor must be over the front panel when the mouse is clicked

in order for the event structure to pickup the event.

As for making it work in you attached vi thats another issue.

You may want to consider using a state machine or other method to organize your code.

II have a case structure inside a loop (state machine), with the case selector wired to a list of available cases (you know, the dropdown box thing that everyone uses for state machines). I had Initialize, Clear Data, Run and Save Data in that list and the case structure showed the names at the top. Everything is good.

4824[/snapback]

I assume you are refereing to an ENUM type

Then I added "No Event" to the list and all of the sudden the case structure switched from names to numbers. So I undid what I just did to go back to the names, and this time I manually added the case to the case structure's list. The case appeared in red (is this bad?) but at least the name is written out.

I can't get the list to include "No Event" (or anything) without the case structure going back to numbers. Is there a limit on the number of cases you can include before it only shows numbers?

(um, I just put quotes around

There may be a better way to do this but here

is what I came up with.

Download File:post-584-1116445688.llb

Download File:post-181-1161869716.doc

I couldn't edit my first post, so I add yet another question here:

I looked at the diagram of <Class> Open Object Reference.vi.

I'm no expert, so why is Flatten to String and then Flatten from String used in the diagram?

Wouldn't a Type Cast do the same job ???????

4761[/snapback]

Yes. in dqgoop it is done this way.

Also "OpenGOOP Data Core.vi" does the opposite conversion.

If you want you can make changes in the "_OpenGOOP_classtpt" folder.

The wizard uses these vis to create classes.

There was another discussion about the OpenG goop here

http://forums.lavausergroup.org/index.php?showtopic=1109&hl=

It has some tips on avoiding issues that other programmers have run into.

Here is the latest Goop Ideas branching off of the dqClass.

DQ3 uses a Que with 2 elements

data is locked when only one item is in the Que

to lock data one of the items is dequeued.

to write new data the Que is flushed and two data items are enqueued.

Download File:post-584-1115993086.zip

I also created a possible core replacment for the OpenG template using the DQ3 Idea.

Download File:post-584-1115994581.zip

DQ4 uses a Que with 1 element and a lock bit bundled inside the Que data.

Data is locked when lock bit is set true.

to lock data the the data is dequeued the bit is set true and then data is enqueued.

to write new data the data is dequeued and the new data is bundled with a false lock bit and enqueued.

Download File:post-584-1115992930.zip

DQ5 Uses two 1 item Ques one for the data and one for the lock bit.

Data us locked when the lock Que is empty.

to lock data the lock bit is dequeued.

to write new data the data is dequeued and new data is enqueued and the lock bit is enqueued

Download File:post-584-1115992961.zip

All of the above allow the data to be read while the data is locked. The original dqclass did not.

Here are my performance test results

Also, in the interest of historical completeness, we would be remiss to leave out Stan Case's contributions to GOOP.  The GOOP wizard he developed while at V I Engineering, and which is presented in the LabVIEW Advanced Application Development course (originally written by Stan, and now managed by NI), provided many of us our first introduction to GOOP.

4683[/snapback]

Thankyou for mentioning this. Stan is acually the one responsible for getting me excited about Goop. I was first exposed to Goop when I attended his pesentation at NI week.

I am glad to see an OpenG version of this.  In part owing to the commitment already made to the OpenG implementation by a number of developers, improvements that can be worked into a drop-in replacement for the OpenG core code would be preferable to improvements that require reworking or scrapping classes already built on the OpenG core code.

I agree, It should be a core replacement and I've already done this with my OpenG Goop template.

But I sometimes tend to jump on the band wagon too quickly and in the past have regretted not testing out new Ideas

or ask for others opinion.

In my initial post I didn't really ask anything so I'll do in now.

Is this the next step in the goop evolution.

Does anyone see any issues, preferences or ways to improve the DQ2 or DQ3 Ideas.

You could change the row and collum property node

Is this what you are trying to do?

Taking The original dqClass I created a new class calling it DQ2 and modified it as I stated in my email.

Download File:post-584-1114495781.zip

Using the TestClassPerformance.vi I got the following results.

Not exactly what I expected. The DQ2Class was much faster at creating and deleting than the openClass but it took twice as long to run the Modify Data vi.

If any one has any ideas why this is so

or got different results please let me know.

Any way the times were not even close to the original dqclass

so I created a new class that eliminated the Semaphores.

Download File:post-584-1114500356.zip

The 3 vis that changes were

Create New

getDataToModify

setModifiedData

And the performance results were much better.

That is what I have so far. Does anyone have anything to add.

With Brian's permission I would like to start a discussion on his new implementation of goop called dqGoop.

For those of you that are not on the OpenG mailing list Brian Gangloff has developed an new way of doing goop using Ques

here is his original zip file.

Download File:post-584-1114495400.zip

It contains 3 different implementations of goop. niClass(Endevo version of goop with locked BD ), openClass(OpenG's version of goop ) and dqClass(new version using ques ). Each of the class have vis that can be used to compare performance.

After playing with the dqClass awhile I replied with some ideas and here was his response.

Hi Mark and Jim,

Thanks for looking at dqGOOP. Since Mark and Jim both brought up the same point, I will just reply to the one and copy everyone in.

Brian

Mark Balla wrote:

>

> Brian,

>

> I was playing around with the dqGoop this weekend. Very nice Idea Goop is probably my favorite LabView topic.

> This approach looks much more elegant as well a smaller footprint. I am very interested in any information you have on performance

> improvements with dqGoop vs. OpenGoop.

>

Did you download the zip file that that was mentioned in the email that

you replied to (bottom of this one as well)? It has 3 test classes,

they can be found in the respective ..\Testing directories. OpenGOOP

does very well on get and set, but the create time is very slow. Please

run the tests on your computer and let me know how dqGOOP compares.

> I have a suggestion to help fix an issue I found.

>

> First the issue

> Because the Modify Data vi removes the data from the Que this leaves the que blank. So any program that needs to only read the data can not

> do so until the data is put back. This creates a bottle neck in Goop vis like mine where several loops only read the object data and only 1 or 2

> vis change it. If I have a Modify vi that takes 500 ms to update the data then all the read vis must wait that time before moving on. OpenGoop does

> not have this issue because the semaphore only stops other programs from changing not reading.

>

It has been my opinion (and I could be wrong), that locking the data

should do just that, lock it. Once the Modify VI gets the data, it is

no longer valid data since the Modify VI is changing it. The question

is then, when you want to get data do you want the latest data (wait for

lock) or is old data OK. dqGOOP currently provides the mechanism for

the first, but as you and Jim have pointed out there isn't a way for the

second. The attached new template could provide a solution for some

instances with only a few Modify methods, but could end up with a race

condition if you had many Modify methods.

I will have to think a bit on how to provide access to old (last before

lock) data. I don't have the time to look at your example code, but

from the description it sounds like too much overhead. If you haven't

yet, read the first three topics in the help file. They give a good

description of why I started to develop dqGOOP, but it all boils down to

performance. I have applications that need to be able to create and

access many GOOP objects quickly.

> I think I found a way to avoid this issue with only a few changes to the core code.

> Suggested Changes

>

> Create New Object Vi

> Instead of a Que size of 1 use a size of 2. Most of the time there will

> only be one data set in the que except when updating changed data.

>

> Get Data to Modify Vi

> Acquire a Semaphore

> Preview Que data. This will still allow others to read it also.

>

> Set Modified Data Vi

> Enqueue the New Data

> Dequeue the Old Data. This leaves only the new data remaining while never

> forcing other vis to wait for data

> Release Semaphore.

>

> I have example code that I've attached.

>

I will look at it but it probably won't be until next week since I will

be out of the office this coming week and half of the next.

> dqGoop may be the concept that brings Goop the the masses.

>

I hope so, but credit has to be given to Endevo for bringing it first

and OpenGOOP for providing the first open source version.

> I don't know if you are a LV8 beta tester or not but this approach

> will fit very nicely with the new LVOOP classes.

>

No I'm not, but its good to hear. I like "LVOOP" class, is that NIs

official terminology?

> Can I request that you please create a post on Lava or OpenG or both

> so we can start discussions with the LV community?

>

Yes, but probably not until I return. Or if you want to start one, I

can join when I return.

> Great concept and thanks for sharing it.

>

Thanks for looking

> Mark

Here is the example code that I attached.

Download File:post-584-1114495473.zip

I'll talk about my preformance findings in a later post.

Taking it to the next level

Try these vis

I have several time vis in my toolbox

that I use all the time.

I posted an explanation on the custom time probes

here.

http://forums.lavausergroup.org/index.php?...2359entry2359

Download File:post-584-1114183839.llb

Thnx mballa with the monoitor I found out there was a non printable character. With the character the program works fine now.

greetings Theo

:thumbup:

4575[/snapback]

Your Welcome

Thanks for the feedback.

The simplest way is to convert the output to a bool array and then use index array to extract out each bit as shown.

if you want to get a little more fancy check out this post

http://forums.lavausergroup.org/index.php?...3969entry3969

Q

I would agree with regis. The sensor needs something to tell it that the string is complete.

If it is not a LF or CR it could be a non printable character like hex 03.

Hyperterminal may be appending a nonprintable without you realizing it.

One of the programs I use is called port monitor.

It shows exactly what is being written and read from the serial port.

you can download it here

http://www.sysinternals.com/ntw2k/freeware/portmon.shtml

I would start portmon and then use hyperterminal and see what characters are being passed back and forth.

good luck.

monitoring the RTS or CTS line. I am not sending or receiving specific bytes of information. Just wanting to detect a voltage.

I needed to do this for a UI device that I built a tester for.

the test code didn't use hardware hand shake lines but the customer application did.

I found that if you use a property node on a serial visa reference it will give you control of the hardware lines.

Hope this helps

I'm Building a production tester that uses a Melexis chip programmer. It came with and Active X toolkit but all the examples are written in VB.

I was able to interpret all the VB code except one part.

The code below scans for connected devices and returns a "Collection pointer"

Sub CreateDevice()

Dim PSFMan As MLX90251PSFManager, DevicesCol As ObjectCollection, I As Long

On Error GoTo lError

Set PSFMan = CreateObject("MPT.MLX90251PSFManager")

Set DevicesCol = PSFMan.ScanStandalone(dtSerial)

If DevicesCol.Count <= 0 Then

MsgBox ("No PTC-04 programmers found!")

Exit Sub

End If

' Dev is a global variable of type MLX90251PSFDevice

There a couple techniques that I use to help control the size of cluster constants.

The first is to arrange the cluster horizontally instead of vertically.

The best one I've found is to put the cluster constant in a subvi and draw the icon so it only takes up half the size of a standard Icon

There is one thing to note when creating the icon make sure to copy the condensed icon to all three color formats in the icon editor otherwise the 256 icon will overlap others. This is shown by the fat const vi.

The editor shows a greyed out area in the icon box that will translate to transparent color when put on the block diagram. If it is white it will overlap.

This idea is also very useful for making smaller icon footprints.

We talked about String and hex conversion in this post it may help you to understand

why the string to hex doesn't work

http://forums.lavausergroup.org/index.php?...3007entry3007

I have to do this sort of thing all the time with field point modules.

If you want to make it a little more readable you can convert the array to

a strict type cluster and then bundle and unbundle by name. I find it much

easier to remember a name instead of a number.

Is it possible to move the label of a terminal on the BD.

I was sucessful moving a label on the FP

but when I try to change the position of a terminal label the proterty node generates an error.

I also tried using the move invoke node but got the same error.