Re: Ride Control System - C / C++ / MFC Discussion Boards

All signs seem to point to mfc, to use multithreading and event handling.

Comments?

Looks like I'm going to have to bite the bullet here and learn mfc. Any recommendations? Advice? Books? Sites?

immanis wrote:
All signs seem to point to mfc, to use multithreading and event handling.

Comments?

[/EDIT Because I did not see that you answert yourself]
Here it goes:

If you have to learn anyway, what about a real framework?
wxWindows, QT if you wants to stay platform independent.
.NET or WTL/ATL if being tied to microsoft platforms is OK.

Biggest question I see here is:
Is Windows capable of doing this near-realtime type of stuff? Or would you better look into a different OS? Client server connected via HTML to have the best of both worlds?

Who is 'General Failure'? And why is he reading my harddisk?!?

From the computing standpoint, the overall strategy for a system like this is typically: 1) collect current state data, 2) evaluate system conditions, 3) provide control output. The collection of data from your vehicles and zone sensors already seems to be handled, so you should know what variables you have that define the system "state." The output of control back to the vehicles or to zone-changing controllers is also a finite set of items, and you should know what those are and how they contribute to the system state.

The logic for evaluating the current system state to determine what the next state should be can be described by ... a state transition scheme. Whether this is a large and cumbersome diagram, or a set of "rules," doesn't really matter. In the field of artificial intelligence, you can create a set of if...then rules to describe input conditions that affect output control, and this is a perfectly good method of determining your logic.

When it comes to programming all of this, sure, you could use a rule-based interpretive kind of language, or code the logic into methods within a class, distinguishing of course between vehicle objects, zone objects, input sensor objects, output controller objects, etc. The overall control of these objects, and their interaction, may become a bit messy, depending on how your control logic is formed, because many times the control logic spans many objects and any individual object may not have visibility over the state of other objects. Coordinating the interaction of these separate objects that need visibility of other objects' state can be tricky, and another approach may make more sense.

If you want each object to retain its independence and be an instance of a class, then you will need other classes that have visibility over all these other objects - the "business rules" class, for example. This is where you would put the control logic.

While timing is another consideration, typical Windows environments are able to keep up with a continual stream of inputs and outputs. But, if you depend on microsecond level timing, then Windows may not be the best choice, as the "real time" aspect isn't there. You don't have precise control over process timing, so by definition Windows isn't "real-time." It may be fast enough to keep up, which then makes it operate in "real-time," but this depends on how tight your time frame is.

Is any of this dependent on MFC? No. There are much larger issues to consider. If there is going to be a user interface, either for monitoring or control, then MFC would certainly provide some answers. But, again, there are other issues to consider.

That's my two cents worth.

Dave

"You can say that again." -- Dept. of Redundancy Dept.

David Chamberlain wrote:
typical Windows environments are able to keep up with a continual stream of inputs and outputs.

As far as I have heard from the engineers in our company, their main problem with windows is not the typical reaction time. With a modern CPU and memory you can get good typical reaction times, but you still have outliers where reaction is much slower.
Depending on the problem, this may be a knockout criterion.

So, while windows may provide a good typical reaction, it can not not guarantee a maximum reaction time.

But I am not an expert in real time programming (not at all) so please ignore me Big Grin | :-D

Who is 'General Failure'? And why is he reading my harddisk?!?

jhwurmbach wrote:
you can get good typical reaction times, but you still have outliers where reaction is much slower.

You (and they) are absolutely correct. One of the primary factors in real-time programs is to be able to guarantee (and therefore predict) response times. Windows can't do this.

In the sense of real-time meaning "fast enough," Windows typically can respond to be able to meet the requirements. But in anything that is time-critical, well ...

Dave

"You can say that again." -- Dept. of Redundancy Dept.

"The overall control of these objects, and their interaction, may become a bit messy, depending on how your control logic is formed, because many times the control logic spans many objects and any individual object may not have visibility over the state of other objects. Coordinating the interaction of these separate objects that need visibility of other objects' state can be tricky, and another approach may make more sense."

Just a wee bit messy indeed!

In the real world, control systems like these consist of multiple plcs and hardware error checking, etc. This program is meant to be a model, so someone could set certain variables into the system, and have the computer run at accelerated time to see what the long term result would be. Later on, I want to add a vehicle capacity component. We'd be able to get a riders per hour count (based on real world boarding averages), and then say, change a dispatch interval, or change a rule somewhere and see what the longterm effects on rider counts would be.

Back to the ride control system

I think the best design would make the vehicles their own individual processes. A main "dispatch" process would give vehicles a "go" to proceed into the ride. The vehicles would also be able to fire events to the dispatch, and the dispatch would respond with either a user message or response broadcast, or both.
I'm thinking the logic and rules for movement should be included in the environment, not the vehicle itself. The vehicles own logic and rules pertain to whether or not it will "listen" to a dispatch command. For example if a vehicle is powered down, it is still exists in a zone, but will not respond to a "go" from dispatch. It may still respond to a "power up" command from the user.
There also has to be a continuous "go" broadcast from the dispatch process to all zones. And that broadcast should have the ability to change to "nogo", "pause" or "stop" depending on either user input or as a response to an event. The dispatch could take an event such as a vehicle taking too long to exit a zone, or intruding on a safety zone and broadcast "nogo" to all vehicles, then prompt the user for appropriate action.

I'm off to school, more discussion later on.
Thanks to everyone who has responded so far.

immanis wrote:
I think the best design would make the vehicles their own individual processes.

Having done several simulations, I want to caution you against implementing your simulation as if it were a real system, and by that I mean that each vehicle being a process is an implementation detail and not an aspect of what you are trying to simulate.

What?

Your simulation model really consists of sensor inputs, processing (state transitions), and controller outputs, where the sensor inputs and controller outputs are "simulated" as opposed to being connected to hardware. To simulate this process flow, you can make a set of processes that each need to react/respond to a controller process, or you could put each vehicle instance in a list of vehicles. On each simluation cycle, you simulate the acquisition of new inputs, iterate through your vehicle list to see what changes they need or what effect the new inputs have, and then you simulate the outputs, by updating the "state" of your world model. It's a very cyclic process: input, process, output (and the time frame of each simulation step is determined by you and is not at all affected by Windows). That is a much simpler implementation than interacting processes, and while I would argue that the simpler implementation is preferable, there is no impact to the underlying simulation that you are trying to evaluate.

When it comes to crunch time, you don't want to have to worry about the implementation as much as whether the control logic works right, and your ultimate goal is the evaluation of a set of input parameters on the performance of the ride (safety, customer throughput, etc). In fact, if you can define an evaluation function for the system "state," then you could use a genetic algorithm approach for finding the best set of input parameters that maximizes or minimizes your evaluation function.

"Yeah ... that's it ... and maybe you could get Loni Anderson to help. Yeah ..."

Good luck,
Dave

"You can say that again." -- Dept. of Redundancy Dept.

Youre right. Making each vehicle its own process is roughly how a real world implementation works, in fact, each vehicle has its own cpu, sensors, and wireless network connection, etc. It thinks for itself. And youre probably right that I shouldnt make the simulation this way. In the real world, the vehicle has to deal with many more variables; variables that would be difficult (if not impossible) to model accurately (such as wheel slippage, motor over/underspeed, brake failure, etc).

But, once I get all the vehicle movement issues down, I do want the program to resemble a real world ride system in many aspects. I dont want it to be a black screen that asks the user for the values to 20 variables, then after a couple seconds, returns the guests per hour. I want to have a live track layout with vehicle location indicators, I want the user to be able to initiate vehicle stop and start commands, and I want the user to be able to change certain settings "on the fly" such as dispatch interval and vehicles on track. I also want there to be different operational modes, such as manual mode, auto mode, test mode and maybe passive mode.
Manual mode would require all vehicle movement inside the station (boarding area and dispatch) to be commanded by the user(through the control system). After the user dispatches a vehicle into the "show" area of the track, vehicle control is given to the iteration system. When the vehicle returns to the station, it will not move unless it is ordered by the user (indirectly through the control system).
Auto mode would be the long term simulation mode, where time could be accelerated, and the station vehicles would be advanced automatically (based on real world load time averages).
Test mode would be where timeinzone and zone safety settings could be modified, to see how the vehicles would behave in a different track environment.
Passive mode is something different. In passive mode, the ride operates in the background, and the user is focused on rider grouping and vehicle load times. The only information displayed would be related to capacity and ride utilization.
Its essentially "The Great Ride Control System Game."
Any thoughts or comments?

"Your simulation model really consists of sensor inputs, processing (state transitions), and controller outputs, where the sensor inputs and controller outputs are "simulated" as opposed to being connected to hardware."

I've gotta write that down, because that is a perfect description of what I'm doing. The sensor inputs are essentially booleans. When the program is done, one should be able to apply the same logic to a real world hardware implementation; instead of a boolean being defined by a virtual vehicle movement function, it will be defined by a sensor, a physical circuit being open or closed.

You really hit the nail on the head there. Thanks for helping to clarify the design in my mind, and on my giant whiteboard.

immanis wrote:
In the real world, the vehicle has to deal with many more variables; variables that would be difficult (if not impossible) to model accurately

This is exactly the basis for an object oriented simulation, since each object can be modeled at different levels of detail. Initially, things will be fairly coarse, vehicle motion will probably be simple movement to a new (x,y) location. Later on, you can make it more detailed, and include acceleration, friction, etc.

immanis wrote:
I want to have a live track layout with vehicle location indicators

So, now you're talking about visualization and how the display of the simulation data becomes usable to a user. I recommend being able to log the simulation states to a file so that later on they can be replayed, perhaps against 2 or more sets of control logic to see which one is preferable. Having controllable inputs becomes critical in simulation design and testing.

immanis wrote:
Auto mode would be the long term simulation mode, where time could be accelerated, and the station vehicles would be advanced automatically

Remember that the time it takes for the computer to simulate the advances from one state to the next will most likely be much faster than how you want that displayed to the user. One strategy would be to increment your local time counter, advance the simulation to the next state, wait for the clock time to catch up, and then display that new state. In this way, user inputs could affect the environment, and the display proceeds at "real" time. For auto mode, to monitor what is going on, you can still provide the display but just not wait for clock time to catch up. Increment time, advance states, display versus increment time, advance states, wait, display.

With operator input being required in certain modes, you could also use this as a training aid and help operators learn what happens when they screw up the schedule, or how to maximize customer throughput.

And the display object can be arranged such that sometimes vehicle movement is displayed and at other times operational parameters are displayed, such as average times, delays, etc.

Overall, what you are describing is called a man-in-the-loop simulation, if you are counting on someone to control the vehicles. At some point, you could also connect some of the hardware sensors or controls and have a hardware-in-the-loop simulation. Both MITL and HWIL simulations are quite useful in many professional (job, paying) areas, so congratulations on being involved.

Dave

"You can say that again." -- Dept. of Redundancy Dept.

Thanks for the advice, it's good to talk to people who know what theyre talking about (although I really dont).

This project is in a pseudo-hiatus-replanning stage now, because I need to learn mfc. I dont think I can learn mfc by doing. I think its important to have a good overview of the capabilities of mfc before I start to use one of its functions.

Any suggestions as to what books to get as a beginner to mfc? Any books or resources (both online and in print) that deal with c++ in control systems?

Thanks again

immanis wrote:
This project is in a pseudo-hiatus-replanning stage now, because I need to learn mfc. I dont think I can learn mfc by doing. I think its important to have a good overview of the capabilities of mfc before I start to use one of its functions.

While I don't understand your ... fascination ... with MFC, this seems to me to be a classic case of "paralysis by analysis." You can't learn MFC by using it? What's up with that? With MFC being a toolkit for implementation, you still have a lot of design work to do. Remember the old addage about design being what you're going to do and implementation being how you're going to do it. You seem to be stuck on MFC, which is much further down the road from where you are now.

Go get a book, almost any book, on MFC. Start reading, start absorbing. But don't let that hold you up on the design. You seem to have a good understanding of what is needed in the application, and you seem to have a good understanding of what is wanted. The organization and architecture of your classes and objects, the rules for the control logic, the state transitions, the inputs and outputs, all have to be laid out in a nice fashion. Use UML diagramming to help keep it straight and help review the essential design elements.

The implementation will come along, and you can slowly add elements of MFC if you want. You may find that you can do what you need without MFC, and if that turns out to be the case, then all your wasted hand-wringing over not knowing MFC will be useless. Maybe MFC isn't the tool of choice for the environment where you want to deploy this software.

You really seem to have a good handle on this project. Just don't let the relatively insignificant issues be the ones that hold you up.

Dave

"You can say that again." -- Dept. of Redundancy Dept.

David Chamberlain wrote:
While I don't understand your ... fascination ... with MFC, this seems to me to be a classic case of "paralysis by analysis." You can't learn MFC by using it? What's up with that? With MFC being a toolkit for implementation, you still have a lot of design work to do. Remember the old addage about design being what you're going to do and implementation being how you're going to do it. You seem to be stuck on MFC, which is much further down the road from where you are now.

I want to be able to use MFC's functions for time, multithreading, and event handling. And later, its display functions. I dont even quite know what they are or how they work, but they look good on msdn. I know I can do all three of these in normal c++, but eventually I want this application to leave the console world, and have a relatively easy user interface. I dont want to sit and convert my application down the line (which people have told me can be a troublesome task). Some people have advised me to just add the mfc functionality I need to my existing application. The problem is, I'm not quite clear how to do that either. Everytime I try to include some mfc header files and define some mfc variables, I get massive errors.

You mentioned UML diagramming, and quite frankly I know nothing about what it is or how to use it. Right now I have a whiteboard filled with boxes, lines and arrows. What exactly is it, and how can I get started?

One of my professors is going to let me borrow an intro to mfc book. Hopefully that will be enough.

David Chamberlain wrote:
Go get a book, almost any book, on MFC. Start reading, start absorbing. But don't let that hold you up on the design.

Oh I cant seem to pull myself away from this program. I dont think it'll hold me up on design, it'll probably just help me identify what specific functions are needed to do what I want to do in my design. I shouldn't have said the project is on hiatus for me to learn mfc, I meant to say actual coding is on hiatus. Design is going on constantly. Design is the best part of the application development process, because everything works the way its supposed to on paper or in your brain. There are no unresolved externals in the design stage. Smile | :)

Okay, so you are further along than I thought. Sure, the MFC book will help and by seeing what functions are available and what they do, you can try to piece them into your code. I suggest that it might be easier to start a brand new project with MFC and a doc/view GUI included, and then patch your existing code into that, rather than trying to add MFC to your existing code. You said you had problems with that approach, so the other might work better.

As far as UML, I assume you've heard of Google? I tried a search on "UML tutorial" and found quite a few good sites. (Here's one: http://www.togethersoft.com/services/practical_guides/umlonlinecourse/[^]). Check it out and see if it would help you. You don't have to document everything. At first, just stick to the big picture items or to the complicated areas where you think you need some additional analysis or review. You can create quite useful diagrams using Visio and then past them into a document with extra descriptive text. It's the beginnings of an electronic document for the project, but the purpose is to help you out as the developer and not to provide every single detail to someone who doesn't really care.

You might try to Google on "MFC tutorial" and that will give you a different view than what msdn provides.

Good luck,
Dave

"You can say that again." -- Dept. of Redundancy Dept.

Thanks for the information, I've got a lot of reading and planning to do.

David Chamberlain wrote:
With operator input being required in certain modes, you could also use this as a training aid and help operators learn what happens when they screw up the schedule, or how to maximize customer throughput.

That is the long term end goal of this program. Operators can see what effect not paying attention, waiting that extra second, double checking the restraint, or just chatting with a child can have on riders per hour. Of course the ultimate goal is not perfect efficiency, as safety would likely be compromised. Every operator is different, and is more or less confident than another, therefore some operators may need more time to be sure that a vehicle is safe to advance.

The program should not be used to make rides less safe, that is quite counterproductive. It should be used to identify and track variances in operational efficiency.

It would also aid in optimizing an existing system. Vehicle load times and group times would be added to the simulation, so one could say something similar to "For every one second the dispatch position has to wait for the vehicle loader to finish loading, we lose x riders per hour."

The program would also aid the supervisors in deciding how many vehicles should be on the track. For example, in one ride at a southern california theme park, statistics have shown that riders per hour increases until vehicles on track equals 14. When 15 vehicles are in operation on the track, it depends on the efficiency of the operators in the station whether rph will increase over the amounts for 14 vehicles or actually decrease. 14 vehicles with a slow station is more efficient than 15 vehicles and a slow station. Such a pattern is not obvious unless one has a model (what I want to create) readily available, or a great deal of hourly statistics (which we had in that study).

hi,
How can i programmatically close a document open using CDocManager::OpenDocumentFile or the file->open command in an MFC MDI application? Please shed some light. Thanks

What happened in the program is I call CDocManager::OpenDocumentFile at a specific time in a day, how do I close a document at a specific time?

If it's an SDI application, you'll never have more than one document open at a time anyway, so a File/Open operation will close the current document before opening a new one. If it's an MDI application, this sounds a bit counterintuitive to me.

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

It is an MDI application, my program has to open a document file automatically at a specific time and close it at a specific time too. Thanks.

You can use the following code snippet to close the active document. Since you are wanting to close a specific document, you'll need to provide a way of finding it.

CMDIFrameWnd *pWnd;
 
pWnd = (CMDIFrameWnd *) GetMainWnd();
if (NULL != pWnd)
    pWnd->MDIGetActive()->DestroyWindow();

Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?

Iwant to read some data from gif file. Dont know how to go about it. Can anyone help.
Thanks

According to what you want to do, one option could be to use OleLoadPicture and the IPicture interface. Have a look to the sample 218972[^] from MSDN.

HTH,

K.

New, what do you own the world?
How do you own disorder?

i would like to set my USB memory stick as a removable media so that it can autorun. does anyone know how to achieve this thru vc++?

can it be done?

if not, how about getting windows to look for the specific USB serial number and 'force' it to autorun?

thanx in advance
m Laugh | :laugh:

Is there anyone know how to do coding which can register an application to Microsoft Sti. From microsoft web site i found this command "IStillImage::GetSTILaunchInformation " but don't know how to apply it. Even I read thru the article but still cannot make it.

I will be happy if source is given.

Thank You Smile | :)

I like to write lines of code that are very short and very simple to understand. Is there a way that I can communicate this in a shorter more compact form?

CEdit *idcinput = (CEdit *) GetDlgItem(IDC_INPUT);
char cinput[255];
idcinput->GetWindowText(cinput, 255);
CString sinput = cinput;

Thank you,
Eric Sepich

don't use C string when using MFC.
replace with

CEdit *idcinput = (CEdit *) GetDlgItem(IDC_INPUT);
CString sinput;
idcinput->GetWindowText(sinput );

Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )