cmschleich
Member
Hi,
I'm using the totalizer block within a user defined instruction. It interfaces with a user defined type tag structure.
I've tested it's operation several times and it seems to work fine most of the time. Every once in a while I get arithmitic overflow errors associated with the totalizer block in my user defined block. Thing is, when they happen, it doesn't matter what the input or totalized values are. I can do a fresh download with 0's, the totalizer enable input is off, and I still get the overflow error (see pictures, -1.$ is the fault). I've triple checked the data types I'm using to interface with the block. No dividing by 0's anywhere.
Anybody seen something similar with this instruction or others? The fact that these errors are intermitent is frustrating. I've seen them in the past, one way I got rid of them was redeclaring the instance of the block and tag structure, literally recreating the exact same tags and deleting the ond ones, and it goes away. Of course that is a total jury-rigged solution to the problem.
I'm using the totalizer block within a user defined instruction. It interfaces with a user defined type tag structure.
I've tested it's operation several times and it seems to work fine most of the time. Every once in a while I get arithmitic overflow errors associated with the totalizer block in my user defined block. Thing is, when they happen, it doesn't matter what the input or totalized values are. I can do a fresh download with 0's, the totalizer enable input is off, and I still get the overflow error (see pictures, -1.$ is the fault). I've triple checked the data types I'm using to interface with the block. No dividing by 0's anywhere.
Anybody seen something similar with this instruction or others? The fact that these errors are intermitent is frustrating. I've seen them in the past, one way I got rid of them was redeclaring the instance of the block and tag structure, literally recreating the exact same tags and deleting the ond ones, and it goes away. Of course that is a total jury-rigged solution to the problem.
Last edited: