Float values being rounded for no reason?

In my PLC I have a value of 8.35324386e-007 in a float tag. When my transaction triggers I end up with a plain old zero in my database table. When monitoring the data in the KepServer quick client it shows correctly as 8.35324386e-007, but when monitoring the value in the transaction configuration it shows 0.000. All the data types for this tag through the entire chain from PLC to SQL database are 4 byte floats, so there should be no conversion issues. Is there any way I can get the actual value instead of the rounded?

What version of Ignition are you using?

7.0.4 (b4594)

I believe that problem is fixed. Please try upgrading to 7.0.8 at http://www.inductiveautomation.com/downloads. If the problem persists please post back.

I noticed a similar abnormality with my Stored Procedure Transaction Groups … I’d have a SQLTag pointing to my device which was reporting a value of 100.05 … when the group executed, the value within the database would be 100. My SQLTag has a data type of Float8 as well as the corresponding item within my group … within Designer, both the SQLTags Browser and Transaction Group are displayed the correct value of 100.05. The values seemed to be getting truncated as though they were being coerced into an integer. For reference, the input parameter for my Stored Procedure was a float as well …

I didn’t have the opportunity to troubleshoot things any further. Monday, I plan on running SQL Server Profiler and executing the group again. Once the groups execute, I can check the trace to see the exact value being fed to my stored procedure.

I’m using SQL Server 2008 … Ignition is I didn’t notice any suspicious messages within the logs …

Sorry I can’t provide more information … I’ll post a reply after Monday’s testing.

Well I finally got the software upgraded. It was a bit of a task because IT had it locked down as if it were in production. Anyway, after the upgrade all my transaction groups now have a gray icon with a cancel sign over them. I can’t edit them and they aren’t running. I tried restoring the backup I took before the upgrade, but it didn’t help. I can’t comment if the rounding errors were fixed yet.

Edit: Newly created transaction groups are the same. Grey background (no cancel sign) and I can’t edit them. Not really sure what is going on here.

Another edit: Figured it out - it is due to using the SQL Bridge limited license. Can’t use standard groups with the limited license.

Yep, thats true - Historical group only.

I ran a trace using SQL Server Profiler … values being submitted to my SPROC by Ignition had the appropriate decimal places …

… decided to look around in SQL … checked out the SPROC, (Disclaimer: which I didn’t write myself) … all the input parameters were of the data type int :astonished:

So, my problem wasn’t caused by Ignition at all … nothing to see here folks, carry on … :slight_smile:

This is getting pretty far off the original topic, but may I make the request that we be allowed to view and edit all types of groups no matter what sort of license is active? You can disallow enabling them based on the license. Recreating groups from memory is a good brain exercise but not good use of company time :slight_smile:

Yes, you’re right that we should probably let you see them, and probably should have some easy mechanism to let you convert back and forth from standard to historical groups.

Here’s a tip though: you can convert them fairly easily yourself with XML export/import.

  1. Export your standard groups (or project) to XML.
  2. Open in a text editor, search and replace typeKey="standard" with typeKey="historical"
  3. Import your file.

As you can see, it’s so simple it should be built in.

Hope that helps,

Two things:
1: Regarding the export, modify, import. I can’t export the standard groups. I assume it is because I am using the limited license because I was able to before with the trial active. What happens is that I get the save dialog, hit Open, but no file is produced. The dialog box goes away as if I hit cancel. Also, when I try to export a historical group, I get an NullPointerException. Stack dump at the end of the post. The XML file produced contains some information but cuts off:

<Project> <Groups> <GroupConfig typeKey="historical" name="Station 60" path="PartData"> <Property name="GROUP_EXECUTION_FLAGS">210</Property> <Property name="TRIGGER_MODE">0</Property> <Property name="UPDATE_RATE">500.0</Property> <Property name="FAILURE_HANDSHAKE_PATH">Handshake</Property> <Property name="DATA_SOURCE">PopDB</Property>
(the file abruptly ends there)

  1. I was still having rounding issues after upgrading, but the license issues I was having took precedence (thanks to all I talked to). Just a few minutes ago I realized that the float4 tags have a default deadband of 0.0001. Setting this to 0 prevents the rounding.

Edit: The promised stack dump:

at com.inductiveautomation.factorysql.common.config.serialization.xml.XMLConfigSerializer.writeProperties(XMLConfigSerializer.java:162)
at com.inductiveautomation.factorysql.common.config.serialization.xml.XMLConfigSerializer.writeConfigObject(XMLConfigSerializer.java:230)
at com.inductiveautomation.factorysql.common.config.serialization.xml.XMLConfigSerializer.writeProject(XMLConfigSerializer.java:149)
at com.inductiveautomation.factorysql.common.config.serialization.xml.XMLConfigSerializer.writeProject(XMLConfigSerializer.java:138)
at com.inductiveautomation.factorysql.designer.FSQLDesignerModuleHook$XMLExportProgressTask.run(FSQLDesignerModuleHook.java:1057)
at com.inductiveautomation.ignition.client.util.gui.ProgressDialog$TaskRunner.run(ProgressDialog.java:208)
at java.lang.Thread.run(Unknown Source)
Ignition v7.0.8 (b4866)
Java: Sun Microsystems Inc. 1.6.0_19[/quote]

Hmm. Could you perhaps do a binary export of the group and send it to support at inductiveautomation.com?


And when I said ‘prevents the rounding’ I meant ‘prevents the software from reading my mind’

Python variables don’t have a permanent “declared” type. You assign to m expressions that are composed only of integers, so the result is an integer. Passing an integer to a %f placeholder converts the value to float at that point just for display.

{ BTW, I almost didn’t make it to your question. I don’t know where you copied the exposition from, but a link would have sufficed. And you would have found abbreviated explanations on this forum if you had searched. }