IGN-11140 toDict() and java.math.BigDecimal

Ignition
1

So this just started happening.... When I call the .toDict() method on Memory Tag, of value type "document" all of the Integers and Floats are cast as <type 'java.math.BigDecimal'>.

parsed = system.tag.readBlocking(["[default]SomeTag",])[0].value

parsed = parsed.toDict()

for key in parsed["chassis"]["abs"]["parameters"]:
	
	print parsed["chassis"]["abs"]["parameters"][key], type(parsed["chassis"]["abs"]["parameters"][key])

Resulting in

>>> 
[1, 2] <type 'unicode'>
0 <type 'java.math.BigDecimal'>
[1, 2] <type 'unicode'>
34 <type 'unicode'>
4 <type 'java.math.BigDecimal'>
N <type 'unicode'>
[1, 2] <type 'unicode'>
0 <type 'java.math.BigDecimal'>
1 <type 'java.math.BigDecimal'>
R86 <type 'unicode'>
0 <type 'java.math.BigDecimal'>
0 <type 'java.math.BigDecimal'>
1 <type 'java.math.BigDecimal'>
1 <type 'java.math.BigDecimal'>

I pulled out what little hair I had left trying to figure out why my test scripts starting throwing KeyErrors when referencing dictionary keys...

Any ideas of why this is occurring? Note: the tag is written as a string and cast 'document' value type.

Thanks!

2

Does the same problem occur if you write it dict(parsed) instead of parsed.toDict()?

3

I fail to see how converted values could make your script raise KeyErrors.
What you're printing is the values and their types, not the keys.
It could be written like this to make it clearer that you're not dealing with the keys:

for key, value in parsed["chassis"]["abs"]["parameters"].iteritems():
	print value, type(value)

Can we see the script that raises the keyError ?

4

We were using the 'ast' library... once I pulled the ast implementation, everything returned to normal-- no casting of java.math.BD

5

Hello guys, can you share how did you remove the "ast implementation" you are talking about? I am having exactly the same issue.

6

We need to see the code to help you modify it. We can't just guess what you're dealing with.

7

In my particular case, my team had imported the "ast" (abstract syntax tree) library for some of the scripting. The library had been purposely added thus removing the library import call stopped my INTs, FLOATs, ect. from being parsed incorrectly, or more precisely- stopped them from being parsed into unexpected python 'privatives'.

8

I've stumbled across this same error.

 TypeError: unsupported operand type(s) for -: 'float' and 'java.math.BigDecimal'

I'm trying to perform a math function on a number that is store inside a document tag.

image

Using the python cast raises another error.

TypeError: float() argument must be a string or a number

The easiest way to resolve this is to use the java method to cast it the correct data type, in my case float.

sourceVolume -= flowIn[flowSource] #This raises the TypeError
sourceVolume -= float(flowIn[flowSource]) #This raises another TypeError
sourceVolume -= flowIn[flowSource].floatValue() #This fixes the TypeError
9

Did you populate the value of this memory tag via e.g. system.tag.writeBlocking with a dictionary, or did you build it in the tag editor?

There's an existing ticket that is probably related if you set the value via scripted write.

10

It's a bit of a convoluted work flow. I am making a process simulation system so there is a lot of data being passed from one tag to another.

UDT 1
Tag1 - Manual write in Tag Browser
Tag 2 - Expression tag reading UDT1/Tag1

UDT2
Tag1 - Written by script from UDT1/Tag2
Tag3 - Script adds Tag1 to Tag3

Not sure if this helps at all.

11

Hi Kevin, is there any updates on this ticket. Just came across the same error for a single value out of many to be cast to java.math.BigDecimal. The value was script written to a document memory tag, and the error occurred on an instance where I duplicated the tag to another folder. The value is 15.

Document tag - script written values, no errors.

Duplicate document tag - copy and paste of the above document tag, one of the values, 15, that were carried over is causing the type error.

Ignition version is 8.1.48 (b2025042910)

12

No, looks like it's pretty low priority. I'll poke the PM. If you contact support to create a ticket that will help visibility and priority.