Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Fri Nov 24, 2017 6:15 am

All times are UTC - 7 hours




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Sun Nov 09, 2008 7:33 pm 
Offline

Joined: Sun Nov 09, 2008 7:01 pm
Posts: 21
Hi,

I am using the DMCCommandExec_1 object for Galil Controllers and I am currently simulating the Qlarity environment for a G58B terminal. When I attempt to use the ResponseReceived event function that you provide I can receive the controller response and then set the property of another object with the response like this:

func ResponseReceived(response as string)
Label_2.value = response
endfunc

However, no matter what I try (and I've literally spent hours), I cannot figure out how to pass this 'response' variable back to a function that I defined in Globals. I want to be able to manipulate the data but I don't want to be forced to do it within this actual function. I've tried things like:

func ResponseReceived(response as string) returns string
dmcquery = response 'note that dmcquery is defined in Globals
return dmcquery
endfunc

And a few hundred other variations but nothing works. Am I going crazy or is there no way to send the information back? And if this particular function somehow doesn't support returning such a value, then why not? I don't want to have to modify the properties of some other object and then read them back through my function in Globals. Although I think this would work, I need to do this quickly and somehow I think this rather convoluted process would cost a lot of CPU cycles.

Also, I typically get this error:

Error GMCCommandExec_1 line 12: Override function error Instance override differs in return type

How can that be? 'response' is a string and I am attempting to return this value to a string. So what is the problem?!?!

Thanks!

BBlair


Top
 Profile  
 
PostPosted: Mon Nov 10, 2008 7:59 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
BBlair,

I see what you are trying to do, but I don't think I understand your motivations. In other words, I see that you want to return a string from your ResponseReceived override event. However, I is not clear to my why you would want to.

What are you trying to have happen by returning a string from that function?

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon Nov 10, 2008 8:43 am 
Offline

Joined: Sun Nov 09, 2008 7:01 pm
Posts: 21
Hi Jeremy,

Thanks for the prompt response.

I need to get a lot of data off of the Galil controller (data streaming in real-time from current motor positions) and also be able to manipulate it all after the fact.

Galil controllers only support array element sizes of up to 16000 (on the newer DMC 40x0 type controllers). I will need to read in data that is much larger in size, say, up to one million elements as they are generated in real-time, and store them in hopefully one array (or more if necessary) on a Qlarity controller which obviously has far more memory to work with (or if necessary, storing up to about 1 MB to the 250 MB Flash drive that is standard on the G58B). To do all this I would be polling the Galil controller at regular intervals of about every 3 ms or so, and constantly getting information for a number of variables.

I would then need to be able to manipulate the data after the fact. The data cannot necessarily be manipulated by the Galil controller itself because it would be too intensive a task as the data is being generated in the first place. So although the Galil controller is capable of manipulating the data, it can't do it at the time it is being generated, nor can it do it after the fact because it can't store it all. Hence, the reason for data streaming to the Qlarity controller and then doing processing offline afterwards. It would also be easier to then process the data in place with Qlarity rather than trying to send it back in small chunks to the controller which (again) wouldn't be able to store more than 16K of it at a time anyway.

Brendan


Top
 Profile  
 
PostPosted: Mon Nov 10, 2008 9:05 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Ok, I think I have a clearer picture now, although there will be lots of gaps to fill in.

You probably don't want to "return" the data from the event function. Why? The event function you receive is called by the GMCCommandExec object when it receives data from the Gail (through the GalilComm object). This implies that returning a string, if it were possible would simply go to the GMCComandExec object's base code and be discarded, which is not what you want.

Assuming you want to store the items you read in RAM (and assuming for the moment that the string format they arrive in is what you want to store) you could read the data as follows. I strongly suspect that you will need to take this example and do a lot with it to make it work for you. But it may be a starting point

Global code
Code:
dim galilStorage[1000000] as byte
dim curStoreIndex as integer

func ProcessDataUpdate(initialStoreIndex as integer, newStoreIndex as integer)
    'Code goes here to process the data
endfunc


GMCCommandExecCode
Code:
func ResponseReceived(response as string)
    dim respBytes[] as byte
    dim initialStoreIndex as integer
    respBytes := response

    'Write the data in the storage buffer
    'Normally we would append, but growing an array to a million bytes through
    'appends can be very slow. So we preallocate the array and copy into it.
    'The code is more complex but orders of magnitude faster
    SetArrayData(galilStorage, curStoreIndex, respBytes, 0, -1)
    initialStoreIndex := curStoreIndex
    curStoreIndex := curStoreIndex + len(response)
    ProcessDataUpdate(initialStoreIndex, curStoreIndex)

    'Next request the next chunk of data
    'The effect of this chunk of code here is to daisy chain command requests so we send out
    'The next request the instant the previous one completed.
    'It is possible that if there is a lot of other Galil activity going on (i.e. objects
    'that need to talk to the Galil, that this will slow us down.  So we may need
    'to switch to using a timer to slow things down so we don't starve, or at least add
    'noticible latency to the other objects

    command = "Hello" '<Pseudocode here: Replaced with the command to issue to collect the next chunk of data>
    executeCommand = true 'Execute the next command
endfunc


A couple of general thoughts on the process:
The G58 is not a real time device. Do not expect real time results. The G58 does pretty well, but it probably will not keep up if you are trying to process 16k data every 3 ms. Especially if you are actually examining every array element.

3 ms, would be extremely aggressive for a polling rate. Our objects support polling at a minimum of 40ms intervals, and to be honest if you start doing a lot of 40ms polls, you are going to bog down the unit quite quickly. I am not familiar with the newer DMC 40x0 controller, however the older Galil controllers couldn't deal with 300 requests/responses per second either. The technique I demonstrated in my example is will probably result in the maximum possible request response rate.

In any workspace where you may be pushing the abilities of the G58's performance, be sure to test your workspace on your unit regularly in addition to Simulation View.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Mon Nov 10, 2008 10:22 am 
Offline

Joined: Sun Nov 09, 2008 7:01 pm
Posts: 21
Thank you very much for such a rapid response and solution Jeremy!

This looks like an excellent starting point. Since I am fairly new to Qlarity I will need a while to study it, add to it, and test it. And as you guessed, I will also parse it as I go to get rid of any extra characters like the ":" or carriage returns that will come back from the Galil controller. This is because I will also be using the VAL function to then get the string into an integer so that the data can be further manipulated in actual calculations. I don't anticpate this being much of an issue as I've done things like this before.

By the way, I don't anticipate any issues with receiving the data fast enough. Perhaps I wasn't quite as clear as I intended. First, the Galil controller will only be talking to one device, the G58B, and it will be the only device on the entire network. Also, every 3ms or so I only need to receive about 15 - 20 BYTES of information, not 16K! When I mentioned the 16000 elements I meant that that is all the Galil controller can hold because that is it's total array size limitation (16000 elements in total are available, spread in any way across up to 30 arrays - therefore not up to 16000 per array).

So in other words, I am balancing the amount of processing the Galil controller must do (there are a lot of other tasks it is doing at the same time), with what the Qlarity controller can do. The most important thing though is streaming the data off the Galil controller in real-time (again, only 15 - 20 bytes every 3 ms - 6 ms due to it's obvious array size limitation). I can then further manipulate the data offline with the Qlarity controller and speed will be of little concern at that point.

Finally, in preliminary tests I have actually already had successful results obtaining the data I need in the required time frame. The output was, of course, just output to a Label and I also obtained the Galil's clock counter to compare exactly how long it was taking. Note that currently I am just using the simulator under WinXP SP2. I will be buying a G58B soon.

Here's something you may be interested in though: Perhaps you folks should speak to Galil regarding an updated driver to use with Qlarity (especially for faster Galil controllers like the 40x0 series). I find that when I just open the latest Galil Tools Lite (free off Galil's website) but do absolutely nothing with it other than "Connect" to my controller, the polling time between the simulated G58B and my DMC4080 is about 42 ms in total for all the data I am obtaining (and this is fine because I'm getting a whole bunch of data back at once - it can be much less if I decrease the data requested). However, if I CLOSE the Galil Tools Lite application then for some reason the polling time between the simulator and my controller jumps sporadically up to 250 ms for the same data requests. It can then drop down somewhat to between 50 - 60 ms. Again, if (while this is occurring), I suddenly just launch the latest version of Galil Tools Lite and connect to my controller, then my polling with the simulator drops to about 42 ms, but sometimes down to 26 ms (again, don't let the numbers themselves confuse you as I am obtaining a bunch of information at once).

My main point is that the reference here is about 42ms, but it jumps to 225 - 250ms once I close the Galil app and sometimes, though usually only momentarily, it might dip to 50 - 60ms. Perhaps you should leverage a further updated Galil driver for Qlarity as they have made some vast improvements in the past 8 months. Of course, I'm not really sure how you've implemented compatiblilty with Galil controllers anyway but I just wanted to mention this. Communication between their Galil software and their controllers was much slower in 2007. In fact, I had a personal hand in bringing issues to their attention and then later testing their new software betas that addressed them. If you wish, speak to DJ at Galil for more information.

Again, thanks. If I run into any real stumbling blocks I'll let you know!

Brendan


Top
 Profile  
 
PostPosted: Mon Nov 10, 2008 10:48 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Readdressing Galil communication is on my list of things to do. We wrote the Galil driver, not Galil, so any changes will have to be made by us.

While I received a fair amount of assistance from Galil in the driver writing, it was done primarily with a GMC-3425 and the manuals for that unit. It has stood the test of time fairly well, needing only minor updates over the past 7 years or so.

I am fairly curious why communication would be better with the Galil tools running. If you have a chance and can run the numbers once you get your G58B, I would be curious to know what differences there are. The QF simulator, of course, uses the Windows network drivers, where all sorts of random things can affect latency. This would not be the case on an actual G58. However, the WiFi might add additional latency with the natural data loss that occurs with radio signals.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group