Beijer Electronics (formerly QSI Corporation)

What features do you want in Qlarity?
Page 3 of 3

Author:  Jeremy [ Fri Dec 19, 2008 7:54 am ]
Post subject:  Re: What features do you want in Qlarity?

Currently Qlarity Foundry will create a manual test harness for objects. We currently use it to test new objects that we create. This feature is hidden by default, but can be enabled if desired.

When using this feature you tell QF what object type you wish to test. QF will then create a series of screens that allow you to exercise all of that object's properties.

I suspect that this is not quite what you had in mind. Can you be more specific as to what types of harnesses you wish to see?

Author:  Fonzy [ Wed Feb 18, 2009 7:15 am ]
Post subject:  Re: What features do you want in Qlarity?


Your product is very nice, however, after working with it only a short time there are some things I would like to see added in no particular order:

1. The ability to create arrays of strings.
2. Hashtables
3. Dynamic object allocation
4. The ability to determine if an object exists
5. XML (including XPath) support to pull data from web services
6. This is wishful I admit but support for JSON as well

I'm not sure how you will be able to effectively add XML and JSON support without the ability to create dynamic object allocations but if it is possible it will really expand your ability to display data from a variety of sources.

In regards to string arrays I realize there is a work around but it's difficult and cumbersome.

The ability to determine if an object exists, or if a variable has been defined, would help make libraries more dynamic. We are building a library for ourselves and our customer that has a lot of objects helping it. Should the customer not want some of these objects the library could check to see if a variable has been defined and if no, it could dynamically kill that feature.

That's my 2 cents

Author:  rhuffman [ Wed Feb 18, 2009 4:21 pm ]
Post subject:  Re: What features do you want in Qlarity?

Are there any plans to add dynamic object creation? If I could add ANY feature, this would be it. I have enjoyed using Qlarity thus far, but this seems to be the biggest issue that consistently comes up. I think that for any project of considerable size this issue becomes a burden because it makes it difficult to manage and organize objects. If an object is composed of several other objects, it becomes a mess to have 5 objects that are only there because they couldn't be instantiated within the only object that SHOULD be using it. There are numerous other problems that come up, each of which can't be solved without dynamic object allocation, or can't be solved without doing something really ugly.

I like Qlarity, but this is a SERIOUS issue in my opinion.

Author:  Jeremy [ Wed Feb 18, 2009 4:38 pm ]
Post subject:  Re: What features do you want in Qlarity?

In response to the two posts today, we are in a design phase for the next major evolution to Qlarity.

Dynamic object creation (in some form) is right up in the top 3-4 things we want to do. XML and better data structures (including arrays of strings and possibly some form of dictionary-type associations) are also high on the list.

We aren't at the point where we have finalized the feature set for the next generation of Qlarity, but thanks for the feedback.

Author:  Ron L. [ Wed Feb 18, 2009 4:40 pm ]
Post subject:  Re: What features do you want in Qlarity?

Regarding 3. in the 2nd to the last post. You should be able to check if an object exists (at run-time). See the code below. You should be aware if using this code that val(obj, objName) is not fast or efficient in large programs as the firmware needs to search the objects for each execution of val in this way.

func ObjectExists(objName as string) returns boolean
    dim obj as objref

    check error
        val(obj, objName)
    on error
        return false
    return true

Author:  rhuffman [ Wed Feb 18, 2009 4:47 pm ]
Post subject:  Re: What features do you want in Qlarity?

I know that you can't give me any exact dates, but when should we expect to see dynamic object creation? This summer? Next year? Thanks :).

Author:  Jeremy [ Fri Mar 19, 2010 10:32 am ]
Post subject:  Re: What features do you want in Qlarity?

We have dynamic objects working on our internal builds right now. If this is something you intend to use, I would suggest you talk to your support contact to see if it will be available on the terminals you purchase.

Author:  mkness [ Tue Feb 22, 2011 9:37 am ]
Post subject:  Re: Polling to read recveived data in serial comport

arka saha wrote:
It would be very helpful to have a polling method or function on comport for checking if data is available in serial buffer and another to read the recieved data.

I would like to repeat this suggestion, perhaps with more emphasis.

IMO, the event-driven model for handling serial communication is simply not acceptable. From a practical point of view, serial port messages are not things that happen asynchronously, like e.g. a user keypress. Rather, they occur specifically in response to a program action, namely sending out some earlier serial port message.

Some specific examples may help show why the event driven comm model is inadequate. Our application involves motion control, so one thing we are concerned with, is the current physical motor position. With a non-event driven comm system, we might write a function like:

func GetPosition () returns integer
SendComm ('request current position')
response = WaitForComm ()
position = ParseCommMessage (response)
return position

Where we send the position request message, wait for the response (which happens promptly), then decode it, and return the position, which actually represents the current state of the motor.

AFAIK, it is impossible to write such a function with an event driven model. Our current workaround, is that our comm event handler will handle the position responses, and set a global variable with the resulting position. Then, somebody who wants to know the current position checks this variable. However - critically - this cached value is NOT necessarily the current position - rather, it is the previous position when the last message came in. This is a potentially serious problem.

Another example would be in handling communication errors. Sometimes the message gets garbled. In a non-event driven system, we could write a function like:

func SendMessageChecked (msg as string)
success = false
while not success
SendComm (msg)
response = WaitForComm ()
if response == ok then
success = true
' else message was corrupted

which would repeat sending the message if the response indicated an error. With the event-driven model, I do not see how to do this.

For a third example, consider a situation where we want to request some motion, wait for it to complete, and then request another motion. In a non-event driven system, we could write:

function IsMoving () returns boolean
SendComm ('get motion status')
response = WaitForComm ()
if response == 'moving' then
return true
return false

and then we could request the desired motion via

SendComm ('do first motion')
done = false
while not done
moving = IsMoving ()
if not moving then
done = true

But with the event driven paradigm, again, this seems impossible to implement.

Author:  Jeremy [ Tue Feb 22, 2011 11:30 am ]
Post subject:  Re: What features do you want in Qlarity?


Please understand that I understand very much how you feel. I have implemented several dozen serial and network protocols in Qlarity, including many which exhibit all of the requirements that you outline.

I have felt the pain of breaking up what would be a fairly simple function that would send data back and forth to a unit into an asynchronous state machine involving multiple functions, and will be the first to admit that it is not ideal (at least in situations where you don't mind the UI locking up during communication).

We have some ideas on what could be done to allow a quasi-polled method of communication to work, while keeping the event driven model in place. I cannot speak as to when we would implement such a technique.

Also, be aware that each of the scenarios you describe can be implemented using the current Qlarity event-driven model, by implementing a state machine. (The code to the state machine is not as simple as your basic functions, but is very doable). If you would like some assistance on that, please feel free to start another forum thread or post a support request

Author:  mkness [ Fri Feb 25, 2011 2:15 pm ]
Post subject:  Re: What features do you want in Qlarity?

Thanks for your answer - I had considered a state machine, but as you say, it is far less elegant - and harder to maintain as well. Ah well. I do appreciate that you are listening to my concerns though.

- Mark

Author:  Doug B [ Tue Apr 12, 2011 11:50 am ]
Post subject:  Re: What features do you want in Qlarity?

Are there any plans to have a web browser object added to Foundry in the near term? Would be very useful for us right now.

Author:  Ron L. [ Tue Apr 12, 2011 12:07 pm ]
Post subject:  Re: What features do you want in Qlarity?

No plans for that in Qlarity.

That feature is available in the software iX Developer.
There are some iX Developer HMI's that will not have web browser support, so be sure to check with your sales representative when ordering.

Page 3 of 3 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group