Are wild MUL results a known bug, or is ML Emulate simply not to be trusted?

So in the end no matter what l select in the status bits the monitor display gives 16 bit result -32768, status table gives a 32 bit result which is correct -42,044,711
 
Both of those screen shots show the plc in program mode. Did you ever put the plc back in run mode with the overflow select bit set to the difference values?

Keith
 
So in the end no matter what l select in the status bits the monitor display gives 16 bit result -32768, status table gives a 32 bit result which is correct -42,044,711

Thank you! I finally snagged one cheap off of eBay, but it will not be here until next week. You may think I am asking stupid questions now... ;)

The -32768 16-bit INTEGER result suggests the [Math Overflow Selected S:2/14] bit is not affecting behavior as advertised in the help file.

I have attached a .ZIP; please try the .RSS in that archive; I expect the [Processor Type] in the [General] tab of the [Controller Properties] dialog will need to be changed to match your hardware.

Caveats, Anomalies and FFEs (Fat Finger Errors;-)

  • The N7:20 value in Rung 0002 (MUL.Source_A) should be 20,077,
    • but it is 2,077,
    • whilst the MOV in Rung 0001 correct.
    • but that should not matter in this case,
    • because the result is greater than 16M (2**24)
      • where any FLOAT conversion, if involved, would start dropping low bits
  • The N7:10 value could be -20,423 to match my original example,
    • instead of 20,243
    • but that only affect the actual bits, not the answer to the OP query.
 
I may have misdirected the interpretation of the result. On an actual PLC I don't think S:2/14 will affect the result in the Dest field of the instruction. I think only the values in the status file can be used to get the correct result. This seems to be another thing that the emulator doesn't get quite right.

Keith
 
if the math overflow bit is set when the program starts rung 0 it will fault the processor
the trick is to cleat the fault bit on the last rung of the program
 
it the way the PLC handles the different data types
with a real / float type they trim the lower bits to fit the are deemed to small in value to be any use.
with an it they don't do that that's why you should never mix the data types
 

Similar Topics

Replies
14
Views
3,344
HI All, I am trying to do some repeat logic on and existing code SLC504. The code is the same just the addresses are different, I have created...
Replies
11
Views
3,327
I am using a ML1400 to count the RPM of several items. They all use the same math to determine the RPM after 10 counts of the counter. The one...
Replies
8
Views
3,256
Hi there every one, I'm working in a PL7 program, (TSX 573623) the existing timer (FTON or %Tm) are working good. The problem is : when I add a...
Replies
2
Views
1,730
http://arstechnica.com/security/news/2010/09/stuxnet-worm-attacks-industrial-targets-could-be-aimed-at-iran.ars Great, all I need is to start...
Replies
2
Views
3,046
Back
Top Bottom