WinSPC version 9.0.11 has been released and is now available for download.
Customers with an active ESC (Extended Service Coverage) account are eligible to receive the new version.
FEATURES IN RELEASE 9.0.11
The following new features are included in this release:
Feature Request 2464: New Ability to Date-Time Stamp Readings Using WinSPC’s API: It is now possible for an API application to set a default date and time and have that date and time automatically assigned to future readings. These future readings include: those collected through the API application, those collected directly into the WinSPC client associated with the API application (such as readings entered directly using a keyboard or via a device), and those that are calculated by that WinSPC client.
One benefit of this feature is that it enables readings to end up with dates and times in WinSPC that match dates and times in an external source, improving date-range analysis and reporting. Another benefit is that it permits a calculated variable to be assigned the date and time of one of the readings employed in its calculation, as opposed to the date and time the calculation was performed, which could be quite a span of time later. This makes it easier to be confident that date-range based searches return the complete set of relevant collected and calculated readings.
The main item that makes this feature possible is a new API property in WinSPC’s Data Collection interface: DefaultReadingDate. Simply by writing a date and time to this property, an API application sets readings to be stamped with that date and time.
Following is an example of the syntax to write a date and time to this property:
DataCollectionAuto.DefaultReadingDate = “MM/DD/YYYY HH:MM:SS”
(Note: The actual format for the date and time, given here as MM/DD/YYYY HH:MM:SS, is dictated by the Windows regional settings on the computer running the API application.)
Clearing a date and time from this property is accomplished by writing an empty string to it:
DataCollectionAuto.DefaultReadingDate = “”
Reading this property’s date and time can be done with this syntax:
Dim defaultReadingDate As String = DataCollectionAuto.DefaultReadingDate
When using this new DefaultReadingDate property to date-time stamp readings collected through the API application, precedence is given to the ReadingDate property, a property that has been in the Data Collection interface for some time. This means that ReadingDate must be null when DefaultReadingDate is to stamp readings collected through the API application. (Unlike DefaultReadingDate, the ReadingDate property has no effect on readings collected outside of the API application.)
Similarly, when using DefaultReadingDate to stamp readings collected via an ODBC Data Source device, precedence is given to that device’s Date/Time field setting. This setting—which is found on the Device Setup window’s ODBC Settings (Cont.) tab—is for a field in the ODBC source that contains dates and times. If it is configured, readings collected via the device will be stamped with that field’s dates and times and DefaultReadingDate will be ignored.
If the ODBC Data Source device condition just mentioned is not applicable and neither the Reading Date property nor the new DefaultReadingDate property are set, readings—no matter how they are collected—will be stamped with the current date and time from the computer on which the API application is running.
FIXES IN RELEASE 9.0.11
Fixes for the following defect numbers are included in this release:
2444: The Location column on the Step Options and the Tag Options tabs, both in the Collection Plan Setup window, now display locations as expected, including those defined for an ODBC device.
3386: List filter descriptions in the top portion of the Data Set Builder now update to reflect the filtering criteria supplied by a user in the Parameter Editor, which is the editor that is sometimes displayed as part of the loading of a data set to give users an opportunity to customize the data set’s list filtering criteria. As a result, the list filter descriptions now represent the current state of the filters, not the configured state.
3822: Part grids in a dashboard now consistently display their labels correctly.
3979: In a dashboard, when a part grid contains a variable grid, the variable grid is now populated with the correct number of variables; that is, the number of variables expected based on the filtering criteria in effect.
4015: The memory issue that occasionally occurred after printing a report and that prevented some subsequent action from completing, resulting in a bug notification related to that subsequent action, has been remedied. The remedy, in addition to resolving this defect (#4015), resolves 24 other defects now known to be symptoms of the same root cause. These other defects are included below in their proper numerical order and reference this description.
4059: See defect 4015 above.
4060: See defect 4015 above.
4064: See defect 4015 above.
4086: See defect 4015 above.
4095: See defect 4015 above.
4100: See defect 4015 above.
4101: See defect 4015 above.
4103: See defect 4015 above.
4128: See defect 4015 above.
4133: See defect 4015 above.
4142: See defect 4015 above.
4151: See defect 4015 above.
4152: See defect 4015 above.
4154: The circumstances that generated a bug report when closing WinSPC, specifically one indicating that the form TProgressForm couldn’t be released, no longer have this effect, allowing WinSPC to close cleanly.
4155: Attempting to close WinSPC by right-clicking the WinSPC icon in the task bar and clicking Close Window now closes WinSPC without errors unless conditions exist that preclude WinSPC a clean closing, such as an undismissed message box, in which case the closing operation is abandoned and WinSPC is left in a running state.
4156: The circumstances that generated a bug report when closing WinSPC, specifically one referencing a problem releasing TTimerReminderDialog, no longer have this effect.
4170: See defect 4015 above.
4179: See defect 4015 above.
4180: See defect 4015 above.
4208: See defect 4015 above.
4215: See defect 4015 above.
4226: See defect 4015 above.
4229: See defect 4015 above.
4231: See defect 4015 above.
4233: See defect 4015 above.
4238: When running WinSPC on an RDP client, double-clicking the X in the Data Collection window’s top right corner to close the active collection plan no longer leaves the Unloading notification visible after the collection plan has completed the unloading process.
4244: Same as 4155. (The difference between these two defects concerns the condition that precludes a clean closing of WinSPC.)
4255: See defect 4015 above.
4261: Archives configured in the month of December to run on a monthly basis now run as expected.
4262: See defect 4015 above.
4273: When running WinSPC via a Remote Desktop Protocol connection, the Data Collection window no longer occasionally loads as a blank window.
4276: The scheduling of archives to run monthly can now be done consistently.
4308: Same as 4155. (The difference between these two defects concerns the condition that precludes a clean closing of WinSPC.)
4327: In a dashboard, when a variable grid contains an organizational component, such as a splitter, the variables displayed in that grid are now sorted correctly.
4333: The rare collection plan configuration that prevented the Unloading progress bar from completing when attempting to exit a collection plan from the Data Collection window no longer has this effect.
4334: When running WinSPC via a Remote Desktop Protocol connection, the RDP client name is now correctly and consistently used as the station name, as opposed to the RDP host name sometimes being used. (Accelerated Defect: 3848.)
4335: Adding an assignable cause to a data point in the Data Collection window no longer occasionally causes a pull-down list of tag values for a related tag to be blank. (Accelerated Defect: 3330.)
4337: The WinSPC Application Server now recognizes and rejects foreign protocol requests, meaning protocol requests from a source other than a WinSPC client.
Your main facility contact should have received an email containing the download information for WinSPC 9.0.11. If not, please contact our WinSPC Product Support by phone (248.447.0140) or by email (support@winspc.com) to request the download information or if you need assistance with the upgrade. WinSPC Product Support is available Monday through Friday, 9:00 a.m. – 6:00 p.m. EST.
About DataNet Quality Systems
DataNet Quality Systems empowers manufacturers to improve products, processes, and profitability through real-time statistical software solutions. The company’s vision is to deliver trusted and capable technology solutions that allow manufacturers to create the highest quality product for the lowest possible cost. DataNet’s flagship product, WinSPC, provides statistical decision-making at the point of production and delivers real-time, actionable information to where it is needed most. With thousands of installed facilities worldwide and distributors across the globe, DataNet is dedicated to delivering a high level of customer service and support, shop-floor expertise, and professional Continuous Improvement, Six Sigma, and Lean Manufacturing services.