Get_IPAddr breaks Simulator in 7.03 build 6

[garysdickinson]

I just broke the simulator, again.

This is the code:

print #1 "before offending statement"
Get_IPAddr 1
print #1 "after offending statement"
[/font][/color]

The Get_IPAddr 1 hangs the simulator and the second print #1 statement never executes.  I assume that the implementation of Get_IPAddr crashed Java.

Get_SubNet, Get_Gateway, Get_SMTP and Get_DNS crash the simulator, also.

I didn't try the Set_xxxx statements to see if they crash the simulator.

The work around is to set a RELAY when running in simulation.  In the  custom functions that have these types of statements, test to see if this RELAY is set and then don't attempt to execute the offending statements.


print #1 "before offending statement"
if !TestIO(Simulation)     ' Execute the following ONLY if not running in simulation.
    Get_IPAddr 1
endif
print #1 "after offending statement"
[/font][/color]

I think that a possible workaround for simulation is to use the status(5) function.  On physical hardware, this function returns a non-zero value related to firmware revision.  On the simulator it returns 0.  I can use this fact to conditionally skip code that breaks the simulator.

It would still be nice if the Get_xxxx stuff didn't break the simulator.

Gary D.

[support]

Once again thank you for your report.  We will look into what caused the simulation issue and fix it for future release. This has no impact on the actual functioning of the PLC. We didn't expect users to simulate this part of the program and that may be why it was not caught during development.

[garysdickinson]

Thanks for adding this to the list.

I use the simulator to debug algorithms as it is faster than downloading to real hardware.  

I do a bit of consulting and do not always have have a test system that matches the customer's hardware.  I try to make all code runnable on the simulator so that I can fix and test stuff quickly even without a physical PLC.

I am aware that the simulator's behavior will not always match the behavior of a PLC so I do test it on real hardware throughout the development.

Actually, I am surprised at how many things the simulator does do.  An example is simulation of EEPROM.  The only things missing is the ability to make the simulated EEPROM 100% non volatile and the ability to save/load EEPROM contents to/from a CSV file.

Thanks again,

Gary d.

[garysdickinson]

The issue with the simulator being intolerant of the Get_IPAddr family of statements has brought up another interesting behavior.

Background, I am attempting to use the value returned from Status(5) to allow a custom function to determine if it is being executed via the simulator or with real physical PLC hardware. I find that Status(5) consistently returns a value of 0 when run under simulator.

Here is where I am getting confused.  This same function, when executed on Fx1616-BA PLC sometimes returns a value of 0 and sometimes returns a value of 90.

I get the value of 0 when I transfer the program to the PLC and select the "Reboot" option on the "program Transfer in progress.."  It can take as many as 9 executions of the Status(5) function with a delay of 1 second before Status(5) returns a value of 90.

If I pick the "Reset" or "Close" button, Status(5) returns a value of 90 on the first call.

I am running i-TRiLOGI 7.03 Buiild 06.

The PLC hardware info: FX-CPU F90.2

This is the "Chk4Simulator" custom function that I am using to test the status(5) behavior:


' check to Firmware Version # to see if this code is being run under simulator
'
i = i + 1         ' Running count of calls to this custom function
A = status(5)

If A <> 0
   SetIO Hardware
endif
[/font][/color]

What am I not understanding about the "Reboot" option when transferring code to the PLC?

Is there a better method for the PLC code to determine if it is running under simulation vs. real hardware?

Gary D.

[support]

There was a bug in the STATUS(5) function on Fx firmware before F90.3 that it only correctly executes when previously queried by a hostlink command.  If you upgrade your firmware (currently F90.7) it should execute correctly.