RunCode - Default Fail

satz

I have some code that is run in DEFINE_START that works on other AMX controller just fine. On an 700 I get the following errors:

(0000018188) CIpInterpreter::Run - Execute Startup Code
(0000018189) RunCode - Default Fail 0x0000 0x000000
(0000018190) CIpEvent::OnLine 33200:1:3
(0000018190) CIpEvent::OnLine 0:1:3
(0000020790) Memory Available = 24782920 <12856>
(0000025104) Memory Available = 24758184 <24736>
(0000025106) CIpEvent::OnLine 5001:1:3
(0000025106) CIpEvent::OnLine 5001:2:3
(0000025107) CIpEvent::OnLine 5001:3:3
(0000025108) CIpEvent::OnLine 5001:4:3
(0000025109) CIpEvent::OnLine 5001:5:3
(0000028195) RunCode - Default Fail 0x7461 0x00047C

In particular it is the error "Default Fail". In both cases I am using a WAIT statement to then call a subroutine. This exact same code is running in other controllers just fine, including a 3100 and 900. I have also seen some other funky behavior out of this device as well all from DEFINE_START. Attempting to assign a VOLATILE variable a value gets an error as was calling the RANDOM_NUMBER library routine (to wait a random amount of time). All this code also works fine elsewhere.

The NI-700 was upgraded to the latest duet firmware. I just downgraded to 2.96.218 and it still behaves the same (erroneous) way.

Any clues appreciated.

Thanks,
Greg

ericmedley

Does commenting out the suspect code make the errors go away?

You may have to go through and comment out the whole program to find the offending code. Finding that out might lead you to figuring out what's going on.
e

satz

I spent quite a few hours reproducing a test case based on a subset of my sources. I can only guess that it is a compiler problem since if I take an already compiled binary for a 900 and download it to the 700 it runs properly. If I try to recompile I get an error on the 700. I haven't tried to screw up the 900 since I don't have a way back to something that works. I can comment out code until it finally works but it renders my code useless to do so. I seem to be stuck in the water. Are there older versions of the compiler available that I can go back to see if I can move forward again?

ericmedley

satz wrote: »

I spent quite a few hours reproducing a test case based on a subset of my sources. I can only guess that it is a compiler problem since if I take an already compiled binary for a 900 and download it to the 700 it runs properly. If I try to recompile I get an error on the 700. I haven't tried to screw up the 900 since I don't have a way back to something that works. I can comment out code until it finally works but it renders my code useless to do so. I seem to be stuck in the water. Are there older versions of the compiler available that I can go back to see if I can move forward again?

You should definitely get on the phone with tech support on this one.

Spire_Jeff

You could also try creating a virtual device (say 36000:1:0) and put your define_start code in the online: event of the virtual. I had to do this to avoid some issues with the processor not being ready to work when define_start was executed.

I would also recommend the call to tech support, but if prefer to continue troubleshooting here, posting the code from your define_start might be helpful.

Jeff

satz

it was my windows VM

Turns out my recent update to my Parallels Virtual Monitor broke my ability to compile NetLinx on my Mac. Going back to real windows hardware created useful output again. I sent a bug report to the Parallels folks. What a wild and painful ride but hopefully this will help others at some point.

Tarl

Damn

I really wish I would have read this one sooner ! Wow can't believe I have gone this long using Parallels with no major issues and now this, had I not seen this I would still be going crazy ! Hope there is a fix soon

Tarl

Parallels

Thanks for the post Satz, any word back from Parallels support on this ? I have also requested a ticket

Scottpulman

a little off topic.... but...

<start shamless plug>

I hate to say it, but that's why you should use VMFusion... I used to run Parallels, then switched to VMWare, not a single issue. ( okay one that was related to a MOXA USB driver, but that was a little weird anyway. ). I actually run 3 virtual's on my MAC, one for AMX, one for craptron and one for the office machine, and every single one of them works great.. I will say one thing, which virus scanner you have running makes a huge difference too, I now run VIPRE and my performance has increased 2 fold over Mcafee.

< end shamless plug >

Tarl

Thanks for the info Scott, I have tried VMware and was not too pleased with performance, but you are right it is know for greater reliability.

Parallels contacted me back regarding this issue and had me follow the following directions and this issue has now been resolved. Pain in the butt, but at least I am back up and running without having to revert back to a PC.

Satz if u got time can u please try this out as well ?

1.> Launch Parallels Desktop, and Start your Guest Operating System[ Windows 7 ].

2.> Please turn off the anti-virus on your Guest Operating System.

3.> Now in Guest Operating System, go to Start=> Control Panel => Programs --> program and feature.

4.> If you find Parallels Tools please uninstall Parallels Tools.

5.> Shut down your Guest Operating System, and Quit Parallels Desktop Application.

6.> Restart Mac.

7.> Please download the Parallels Tools from the article given below and follow the article to install Parallels Tools.

http://kb.parallels.com/en/8296

8.> After the Parallels Tools installation Please restart the Windows.

9.> Please click on Virtual Machine on the Mac menu bar --> Configure --> Options --> Shared Profile --> disable it.