Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Previous section Next section Previous page Next page Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Page 1 of 2
Topic:
Jump & Execute won't simulate
This thread has 16 replies. Displaying posts 1 through 15.
Post 1 made on Saturday September 18, 2010 at 13:34
rap
Long Time Member
Joined:
Posts:
September 2006
59
Coming up to speed on PEP2, latest version and latest version of firmware.

Working through a project I noticed that jump & execute doesn't work in the simulator but works just fine on the TSU9400 panel.

I have a button with one action-> Jump & Execute

The landing page immediately jump to Please Wait #1, cycles through a few actions and jumps back to where I want it.

All works on the TSU fine, it will not simulate though.

However, a simple Jump command will.

Any clues?

Thank you,

OK...Just noticed the "CommandFailed on the simulator panel. Buy why? I deselected the "Extender" and voila, the simulator began working. Does this make any sense? It seems nuts-o to turn the extender off on all the device to test/simulate and need to enable it before loading the panel. This can't be, can it?

Last edited by rap on September 18, 2010 15:03.
Post 2 made on Saturday September 18, 2010 at 15:15
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,992
Yes, there is a thread somewhere in this forum about the fact that you must remove extender from components before you can properly simulate in PEPv2.

Try a search for simulator extender.
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 3 made on Saturday September 18, 2010 at 15:38
rap
Long Time Member
Joined:
Posts:
September 2006
59
Right you are Lyndel. I tried various searches and did not find that. The sad part is that it's reported back in January of this year and now it's September! No fix...

Why would Philips do that? The point is to simulate, you don't really want it to talk to the extender and start firing off commands. Just simulate...
Post 4 made on Sunday September 19, 2010 at 00:17
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,992
Well, the reality is that the software used in the simulator is the same software used on the remote but a Windows version including javascript integration. If this feature were enabled, then you could, in theory, just launch the simulator on a PC and never have to purchase a remote (although the scroll wheel simulation is less than optimal).

Search for Jon Welfinger TCP simulator and you can find a way around this.
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 5 made on Sunday September 19, 2010 at 10:42
buzz
Super Member
Joined:
Posts:
May 2003
4,366
In most cases my RS232 devices go through a single service routine. I use a conditional statement to print a note on the simulation console rather sending to the extender. I am not attempting simulation for two way.

This works OK for me because most of my programming is done offline -- there are no network resources.
OP | Post 6 made on Wednesday September 22, 2010 at 16:40
rap
Long Time Member
Joined:
Posts:
September 2006
59
Lyndel - I"mjust looking to simulate the sceens, jumps, and visual items. I don't really want to "simulate" with connectivity to the extender. That's more like an actual testing of the commands which I don't mind doing with a download. The commands most always work and need little tweak. The user interface, however, requires a lot of twesking.

buzz - can you explain a little more about what/how you do your simulation? It sounds like it might work for me.

thanks all!
Post 7 made on Wednesday September 22, 2010 at 21:16
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,992
You will NOT be able to simulate if you try an execute any button or an action list for an activity includes an IR code or RS232 code is present for a component that is attached to an extender.

For normal jumps, this will be OK. However, let's say that you enter an activity and as part of entering an activity, you are sending IR codes to switch inputs while jumping between panels or the IR Code action is inside the default actionlist of an Activity. If the component containing the IR code is indeed attached to an extender, you will get command failed and the remainder of the actions in the actionlist will never be executed.

It is highly likely that once you have a production-ready configuration, you will have such actions in an actionlist as you will likely be setting up your equipment for the task-based activity (Watch a DVD) you are entering. For example:

Jump Working-Please Wait 1
TVON
Jump Working-Please Wait 2
Amp On
DVD On
Jump Working-Please Wait 3
Set TV Input to HDMI1
Set Amp Input to DVD
Jump Working-Please Wait 4
Set Surround Mode DolbyPLII
Jump DVD-Transport
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 8 made on Friday September 24, 2010 at 08:20
rap
Long Time Member
Joined:
Posts:
September 2006
59
My take is that simulate is just that and should not allow any "live" actions. Developing the UI is one task that requires testing for flow logic and graphics presentation and then the activities need to be tested to see that they work as designes. The latter, in my view, is not simulation because it's running live actions. Sort of like flying a plane in a simulator - you think and appear to by flying it but you really are not.

I do see the value in having the simulator fire off live commands for testing the configuration to ensure the activities are acting as designed. It saves the download time and will be more convenient.

I do hope that if/when Philips officially enables it that they provide a flag to enable/disable the TCP communication and allow true simulation with devices defined using extenders.

Just my view...
Post 9 made on Friday September 24, 2010 at 08:33
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
See in my eyes the testing of the performance of the design (that it does what is supposed to do) is simulation. To be able to simulate the entire confing with all the communication is what I expect from a simulator, because downloading the xcf to the control panel can be a real nuissance, but it is also time consuming. Plus you don't have any "debug" tools on the remote.

My xcf's are always hardware dependant, so without hardware my scripts do almost nothing. In this way I can't test scripts if I don't have access to the hardware with the simulator.

True you always have to do the final testing on the remote as performance on the remote is different than in the simulator.

Another benefit if the simulator works with the hardware is that you can develop your entire xcf before you order the TSU.

So I'm towards the idea of a fully functional simulator, otherwise for me is like developing a pc application that interacts with some hardware, without being able to use the hardware.
OP | Post 10 made on Friday September 24, 2010 at 09:27
rap
Long Time Member
Joined:
Posts:
September 2006
59
You make some good points Blu.

I'm just holding to the true definition of simulate which is to do something "as if" you are really doing it without actually doing it. Did that make sense?

So with my definition, to have a true Pronto simulation environment we would need to have emulators for the hardward devices that the simulator could interact with. With hardware emulators you could then monitor/change the state of inputs/outputs and test the panel completely without having projectors going on/off, drapes opening and closing...etc numerous times which can't be good for the equipment.

I think having an "enable flag" in the simulator will suit a lot folks.
Post 11 made on Friday September 24, 2010 at 10:44
Barry Gordon
Founding Member
Joined:
Posts:
August 2001
2,157
It all depends on what you are trying to do. In my situation I only do TCP/IP And UDP in the pronto. I use no extenders. I have my own "Extender" in the form of a server program running on a PC.

I therefore want the capability to receive and respond to external devices using TCPIP or UDP. I believe the current implementation with Jon's changes does a reasonable job but may have issues with multiple responses when each ends with a CRLF sequence. (Have to remember to speak to Jon)

I would also like the option of registering a stub with the simulator (written in some sensible language) that the simulator would call when a TCPIP or UDP sequence was issued. I get around that today by having a setting in my TCPIP library to simulate a result via table lookup. in that way I can "Simulate" various responses from a device I do not own. The stub would return an expected response to test out the logic without the need for the physical device.

When doing complex TCP based IO with poorly documented external devices you always need the physical device sooner or later!
OP | Post 12 made on Friday September 24, 2010 at 13:05
rap
Long Time Member
Joined:
Posts:
September 2006
59
Barry, I agree completely.
Post 13 made on Friday September 24, 2010 at 13:34
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
On September 24, 2010 at 09:27, rap said...
You make some good points Blu.

I'm just holding to the true definition of simulate which is to do something "as if" you are really doing it without actually doing it. Did that make sense?

So with my definition, to have a true Pronto simulation environment we would need to have emulators for the hardward devices that the simulator could interact with. With hardware emulators you could then monitor/change the state of inputs/outputs and test the panel completely without having projectors going on/off, drapes opening and closing...etc numerous times which can't be good for the equipment.

Ok here I fully agree with you, you need to simulate the hardware as well for a simulator to be a simulator. I mainly come from the embedded world and there in the simulators you can adjust the variables that depend on the real world so you can fully simulate the system.
Well about the "cant be good for the equipment", the equipment must be built in a way it works for n-tries, I mean the usage you make of the hardware compared to the lifetime it will have at the customer's home is infinitesimally small and if it fails in your lab, can't be good for the customer :).

Agreed Barry, the simulator needs to be extended (or even better, rehauled).
Post 14 made on Saturday September 25, 2010 at 06:14
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
12,992
A bit of history for those coming on board who exclusively use PEPV2.

The name Simulator came from PEPV1 where it did exactly what rap wants it to do and nothing more. In fact, for those of use who were used to the NG and classic prontos, PEPV1 was a step backward.

Then, PEPV2 came along and they added javascript debugging effectively changing "Sim" to "Em" and the darned thing was never renamed to Emulator.

So, now, it is a slightly castrated Emulator that only fully emulates with Jon Welfinger's extension software.

;-).
Lyndel McGee
Philips Pronto Addict/Beta Tester
Post 15 made on Saturday September 25, 2010 at 06:54
BluPhenix
Long Time Member
Joined:
Posts:
December 2008
371
On September 25, 2010 at 06:14, Lyndel McGee said...
a slightly castrated Emulator

Oh that made my day, thank you. I believe this is the best definition for the current state. Looks like an emulator (man) but lacks the main part that defines it.

lol
Page 1 of 2


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse