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

Hi,

I far as I can remember there is something like a negative height. When the height in the logfont structure is positive it is the height with the leading, when the height is negative it the cell height. But I do not know if it's just the ascending or the ascending+descending.

I vaguely remember that the TEXTMETRICS structure has members for ascent descent and so on.

So for your code the line
HcarFromFont = Metrics.tmAscent should do what you need;

Regards

G. Steudtel

yes indeed I use a negative lfHeight, it means that height is the character height (ascent + descent, including an internal leading); a positive lfHeight would mean the cell height (= character height + external leading).

G. Steudtel wrote:
HcarFromFont = Metrics.tmAscent should do what you need

so I presume I write :

lf.lfHeight = -HcarWanted; // first try : HcarWanted = 10 mm (in pixels)
font.CreateFontIndirect(&lf);
pDC->SelectObject(&font);
pDC->GetTextMetrics(&Metrics);
HcarFromFont = Metrics.tmAscent;
lf.lfHeight = -HcarFromFont;
font.CreateFontIndirect(&lf);

But don't forget that CreateFontIndirect(&lf) will consider lf.lfHeight as the total character height, how can it known it's meant to be the ascent height ?
Or is there something i didn't grasp ?

Nevertheless I did test the above code : it does not work : the font is now much too small; suppose the initial height was 10 mm : say 6 mm for ascent and 4 mm for descent; so with the 2nd assignment of lfHeight, i will ask a font whose total height is 4 mm.

Hi,
Sorry that I made it too short. Off course if you take a smaller value you get a smaller font. The fault is by me for not thinking any further.

Two approaches:
1) In a loop increase the height of the font until tmAscent becomes 10.
2) HcarFormFont = INeededHeight*Metrics.tmHeight/Metrics.tmAscent; with iNeededHeight being a constant of 10 ( or what ever height you need).
I'm not so sure about the calculation but the ratio of height to ascent should be the factor to increase the height of the font. Also you should do some casting to double and back to integer to minimize rounding errors. But basically the second method seems reasonable.

Regards

G. Steudtel

In my first code, i did a similar interpolation that the one you suggest.
HcarFormFont = INeededHeight*Metrics.tmHeight/Metrics.tmAscent.
Nevertheless, using your formula or mine, the results are very near, and on screen the font looks either too small, either too big (it depends of the font).

Note that, curiuously, after having set the height with the interpolation formula, if i request again the metrics with GetTextMetrics(), i see that the height of ascent part is now equal (or very near) to the initial height i requested. So the formula seems to work, and yet on screen that's not OK...

Thanks,

JPG

For any office document and many other documents as well, you can edit the document's set of properties by right clicking the document's icon, and selecting the summary prop-page. There are for instance etries like "Document title", "Comments" and "Keywords".

In my code, I would like to access this information. That is, given a filename, I want to check if the correspondning file has an entry "Comments" and reads its value.

Can anyone with this knowledge share some hints or, Poke tongue | ;-P

even better an example?

Regards // Jonas Pettersson

http://www.codeproject.com/cpp/cppforumfaq.asp#win_summaryinfo[^]

Michael

'Logic, my dear Zoe, merely enables one to be wrong with authority.' - The Doctor: The Wheel in Space

Thanx Michale for your help! It got me almost there... I have now extracted the information I wanted from all the Office documents in my application.

The thing is that I also need to do the same thing for a bunch of JPEG-files. Reading the article You proposed, I understand that IStorage and IPropertySetStorage only applies for compund documents, such as the Word documents You helped me inspect. The JPEG files aalso have properties like this - is there another way to access their properties Confused | :confused:

? Or is their properties stored elsewhere than in the file?

Once again, thank you Big Grin | :-D

Jonas Pettersson

Hello all, I'm an engineering student looking to go into control systems engineering and automation.
And just because I'm so interested in the field, I've started working on a ride control system (theme park ride) model written entirely in c++. I've designed and written the code for the vehicle, zone, and track objects.

Now,

My current plan is to have ride vehicle motion be powered by a near-infinite loop, with the program going from zone to zone checking zone status and advancing vehicles if certain conditions are met.

Heres a quick outline of how it basically works
Say we have a vehicle, called veh1. veh1 is located at zone 1 on the track. Now, zone 1 has its own characteristics such as integers timeinzone and zoneclearance. timeinzone is the minimum number of milliseconds the vehicle has to spend in the zone before it is able to advance to the next zone. zoneclearance is the number of zones that must be unoccupied ahead of the current zone for the vehicle to be advanced. So, back to veh1, the control loop checks zone 1, sees that veh1 is present, checks how long veh1 has been there (time at zone entry is also stored), and if a move is to be made, it checks the following zones (to comply with zoneclearance) before it gives the go for veh1 to move.
Every zone can have different values and requirements for advancement. There are also certain maximum values and vehicle safety zones that will return errors or stop all vehicle motion if they are intruded.

And, the help I need

I dont think the way i'm doing it right now is very efficient. I was wondering if there was another method to go about this. Keep in mind that I know only console c++, ZERO MFC.

In a perfect world, each vehicle would almost be its own pseudo-sub-program, and evaluate the conditions on its own. Can I do this in C++? There would be several vehicles, in a predefined environment, and they would decide "on their own" what the next logical move would be and send the information to the main control or user console. User intervention would only be required on errors, and all vehicles could send messages to the console, or even to a log file. It would be somewhat event-driven. I suppose its a level of artificial intelligence too. Except that there will be several "robots."

Any help or comments would be appreciated. Even the "YOU SHOULDNT BE WRITING THIS IN C++" comment is welcomed, just tell me what language you feel would be better.

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?