Search Sort Posts:  Oldest to newest Newest to oldest

05-31-2005, 2:25 PM barrett Joined on 04-07-2004 St. Louis, MO Posts 27 G70 & G75 Foundary Issues If you use the G70 or G75, you know that the application is called QSI Foundary. I just found out that even though the web site nor the readme files mention this, you need to get the file "qsidefines.txt" and include it in the download of the ioControl strategy control engine configuration if you are using Foundary version 2.12 and ioControl version 6.0 or later. Turns out that the developers forgot to mention they removed this little definition to QSI who depended on it for communication to the terminals.    Report

06-01-2005, 11:23 AM mstjohn Joined on 06-04-2003 Temecula, California Posts 18 Re: G70 & G75 Foundary Issues Correction/clarification on this issue: ========================== This file is ONLY needed when: * using ioControl subroutines and * displaying a string on the G70/G75 Here's a link to that file to include in the strategy. www.opto22.com/support/softwareDrillDown/softwaredrilldown.aspx?SoftwareID=119 Also: Opto's version of Qlarity Foundry 2.12 isn't available yet. The subroutine/string problem, though, does apply to the current 1.53 version that is available. The upcoming version of Qlarity (expected out in 3-4 months) will eliminate the need for this file. More details for those interested: ======================= We developers did not actually remove a definition and forget to mention it to QSI. (This bug was much more subtle and involved.) There were many, many, changes and improvements made to 6.0. The biggest, adding subroutines, required changing quite a bit of the fundamental building blocks in the control engine. Unfortunately, one change broke the method currently used by QSI to display strings, if you happen to be using subroutines. We've been working closely with QSI as they develop their upcoming version of Qlarity--which will include various improvements including support of High Density Digital modules. The upcoming version will no longer need this text file work-around because it will use the same method of extracting data from the control engine our Opto 22 software uses. This will not only speed up control engine reads, it will also reduce the odds of another bug like this creeping in unnoticed. In general on bugs/known issues: ======================= When it comes to bugs, these aren't usually documented until we post a readme listing all the fixes included in the latest-and-greatest software/firmware. However, with the forums and now blogs, we're working to increase the bandwidth of information flow between the developers and customers. For example: www.opto22.com/company/rss/products_blog/archives/2005/06/important_infor.aspx Let us know if you have suggestions for how we could improve our methods for sharing information. -Mary St.John Opto 22 Software/Firmware    Report

06-03-2005, 5:56 AM barrett Joined on 04-07-2004 St. Louis, MO Posts 27 Re: G70 & G75 Foundary Issues Thanks for the clarification, Mary. I do need to mention that I think (thrid party over the phone) I had a case where my client was able to negotiate the screen menus, the UIO was still controlling some pumps (indicating it was not locked up), and my client was not able to get any of the push buttons or analog set point values to respond. This would appear on the face of it as a communication issue. I can't specifically say what this was related to, but thought you should know I was not using subroutines, however, I was using the text list box on the G70 to display alarm messages from the UIO. While I have your attention, the most reliable performance I have had with the G70 was using verion 1.53 with the UIO 1.0c where I was communicating primarily with tables to the scratch pad area to load the values up to the G70. On writes from the G70, I used a script in the G70 to send a text address of the value being sent and then the UIO would use pointers to read and load the value into a corresponding variable in the UIO. I accomplished this in part by using an Excel scripted spreadsheet to generate a formated text list of variables which I was able to insert directly into a UIO script block which was used to load the pointer table on startup. My question is: Since every individual communication event to the UIO is taking up processor time, is the difference between using the opto tag driver in the G70 versus the use of a table system descibed here in communication efficiency enough to significantly slow down the UIO? Why not program the G70 to only do block reads from the UIO of any and all variables and just use individual tag value writes to the UIO when and operator make a change (which is very seldom). Barrett Davis    Report

08-22-2005, 1:39 PM barrett Joined on 04-07-2004 St. Louis, MO Posts 27 Re: G70 & G75 Foundary Issues Well Mary, they say it ain't so....    Report

OptoForums » Application For... » Systems Integra... » Re: G70 & G75 Foundary Issues

(please select) Forums Home |- Search Forums |- Active Topics |- Unanswered Posts User Options |- Sign In |- Join this community |- Forgot Password Product Forum |- SNAP PAC Systems |- Other Hardware Systems |- Other Software |- Protocols and Drivers |- SNAP PAC Learning |- Shoot This, Opto! Application Forum |- Automation, Control, Data Acquisition, and Remote Applications |- Systems Integrator, VAR, and OptoPartner Section |- Where's Your Opto 22? International |- Opto 22 in Latin America |- Opto 22 Forum for French (Français) Speaking Customers