FYI - through some digging, I've discovered that all the necessary code to do TCPIP communications is already buried in the existing simulator program.

I've created a proof-of-concept app that has enabled TCPIP communication from the simulator. So far all socket communication to IP devices works fine, but no communication with my RFX9600 extender yet. I'm going to continue working to get the extender functionality as well, but at this point I don't know if that is possible. With just the TCP communication working, this is still a HUGE help and time saver for debugging.

I spent most of today working on some scripts for my home automation controller and I was able to do it from my office over a VPN connection to my home controller. No need to download the program to the TSU9600 and run a terminal program with the serial mod. I can't even begin to tell you how much time this saved me!

After I do some additional testing and can create some documentation, I'll be posting up the info on how this is possible. I will also be supplying a couple of EXE's that facilitate the loading of the simulator with the TCP socket functionality enabled.

Stay tuned!

Jon

This would be really useful to have for the stuff you describe as I am trying to do a development talking IP to iTunes and it is really painful having to go via the Pronto. So don't wait too long before you give us some hints! If you are happy to give some hints privately over a PM then see my profile!

Simon

Simon,

I'll PM you when I have something ready. I hope to have something put together this weekend for people to download.

I'm a little surprised that there's not more interest... :(

- Jon

I am interested. I do a ton of tcpip and being able to do it without d/l and test would be great

I've had something for a couple of weeks, that was sent to me from a very curious Pronto "newbie".. Works great!

If you have no luck let me know I'll talk to him and see if he wants to put his little hack public.

Do you have extender communication working from the simulator?

I have packed a couple of EXE & INI files into a ZIP file for e-mailing.
Anyone who would like to use this should e-mail me at the address in my profile.


Here is the README.TXT from the ZIP file I have created:
===============================================================

The original Philips files that will be discussed are listed below for reference:
[ProntoEdit] = C:\Program Files\Philips\ProntoEdit Professional 2.0\ProntoEdit Professional 2.0.exe
[msf.exe] = C:\Program Files\Philips\ProntoEdit Professional 2.0\Simulator\msf.exe
[appli.exe] = C:\Program Files\Philips\ProntoEdit Professional 2.0\Simulator\appli-win32\bin\appli.exe

Under normal operation of the simulator, the executable [ProntoEdit] calls the executable [msf.exe] which in turn calls the executable [appli.exe]. What needs to be done to modify the simulator behavior is to intercept the calls to both [msf.exe] and [appli.exe] and change their parameters on the fly. This is accomplished by the use of "stub" files that are used in place of the original executables.

The original operation of the simulator has executables called in the following order:
[ProntoEdit] ---> [msf.exe] ---> [appli.exe]

After renaming the original msf.exe and appli.exe to msf!.exe and appli!.exe, you can then copy over the new supplied versions of msf.exe and appli.exe.

The modified operation of the simulator will have executables called in the following order:
[ProntoEdit] ---> [msf.exe] ---> [msf!.exe] ---> [appli.exe] ---> [appli!.exe]



The folder [C:\Program Files\Philips\ProntoEdit Professional 2.0\Simulator\] should contain
the following files (in addition to any others that may already be present there):
msf.exe = new executable to intercept calls to the simulator.
msf!.exe = Philips provided msf.exe that has been renamed.
msf!.ini = new config file for setting runtime options of msf!.exe

The folder [C:\Program Files\Philips\ProntoEdit Professional 2.0\Simulator\appli-win32\bin\] should
contain the following files (in addition to any others that may already be present there):
appli.exe = new executable to intercept calls to the simulator.
appli!.exe = Philips provided appli.exe that has been renamed.
appli!.ini = new config file for setting runtime options of appli!.exe



The following entries are contained in the INI file and can be modified for experimentation. For normal operation, all entries should be set to YES.

PROCESS_ENTRIES=YES
Setting this to YES will turn on parameter processing and setting it to NO will turn it off. This is useful for when you want to see the unmodified parameters that ProntoEdit is using.

AUTO_RUN=YES
Setting this to YES will cause the "stub" file to call the original file without intervention. Setting this to NO will cause the "stub" file to pause to show you the command line parameters prior to execution of the original file.

AUTO_CLOSE=YES
Setting this to YES will cause the "stub" file to automatically terminate when the simulator terminates. Setting this to NO will cause the "stub" file to pause to show you the command line parameters that were used. This is useful for modifiying parameters and re-launching the simulator without having to quit all the way back to the ProntoEdit program. This is mostly for testing parameters only.

Outstanding! I'd love to give this a road test.

All e-mail requests have been sent! Any feedback would be greatly appreciated.

- Jon

Hello Jon,

great tool! Everything I did by myself works until now. But unfortunately SlimPronto94 does not work. Has anybody else the same experience?

best regards
Winfried

Thank you Jon for the application! It is working!

My experience is the same, SlimPronto94 is not working but picture app. and weather module work. Is it possible to use the extender with this application? That is not working right now.

Johan

I can add that CPU is upp 100% all the time when the simulator run with aplli.exe, appli!.exe and msf.exe in the top in CPU level. The PC that run ProntoEdit is not that new, Pentium 4 3Ghz with 3 Gb ram.

It work with tcp/ip to girder.

My guess is that the connection is to slow and it is to much traffic with SlimPronto, the applications with less traffic works.

I've tweaked it a bit to lower CPU usage (basically zero) for both appli.exe and msf.exe, but I can't control how much appli!.exe uses during TCPIP communications as that is the original Pronto simulator program.

I'll send you an update to test.

That is why I do not use the simulater. The original docking station debug mod gives a proper display and does not care how hard the xcf in the pronto is working, or how much tcpip traffic is being thrown.

The simulator does spike the CPU, but it's not a big deal to me. The benefits of developing/debugging without having to download or even have a Pronto with you far outweigh any CPU utilization issue.