DELMIA QUEST and Manufacturing Simulation

HTML5/JavaScript MT Connect Viewer

2011-07-13T10:12:00.010-04:00

In my last few posts, I've talked about what MT Connect is, how it works, and why CCAT is excited about it. Now I want to talk about a proof-of-concept web-based viewer I've created for viewing the real time status of our machine lab.

As I said before, an MT Connect agent provides the current status of the devices talking to it, by returning an XML string with all the details in it. Since the advent of AJAX it's been very common for developers to create web-based applications that hit a server for XML data, and on loading it, modify what's being shown on a web page (using DOM manipulation). This is basically the strategy I wanted to take, with the added feature of using the HTML canvas element included in modern HTML5-compliant web browsers. The canvas basically allows you to draw in 2D on a portion of a web page. The great thing about using HTML and JavaScript is, it works on any platform that supports HTML5 features (including iPad/iPhone/Android browsers).

One reason I chose the canvas element was because we had built a flash-based viewer a few years ago for a single machine, which just listed out some of the MT Connect data we were getting in real time (spindle speed, etc...). But now we have three machines (and maybe more in the future) that we'll want to be able to view at the same time, so I thought having an overhead view of our layout would be a cool way to get heads-up info on what's happening in our lab.

Luckily I had built a basic JavaScript library for creating and drawing 2D shapes on a canvas when learning JavaScript. So all I really had to do was write some code to interrogate the Agent, extract data on the machines I wanted to know about, update the 2D shape objects with the right information, and let my graphics library handle the graphics.

So to start, I used a VBA macro in Visio to export my 2D layout to JavaScript code that would create 2D shape objects in my graphics library format. So at this point I had a canvas element that would draw our machine lab layout, which was a great start.

I then added a JavaScript function that uses JQuery to get an XML string from my MT Connect Agent detailing the current status of my machines. I also used JQuery to convert the XML output into the JSON format, which converts the XML data into native JavaScript objects, and step through the XML tree to find what I need.

All that was required now was a function that would get the current status information as JSON data, and map that data to my 2D shape objects, and then call itself after some interval (using setTimeout). So I wrote that function, and it works pretty well, just turning machines different colors depending on their current state. You can click on a machine, and see some more detailed information pop up on the side.

I've also played with storing the last 150 spindle locations and drawing that on top of the machine, but the problem there is converting the spindle locations into relative locations within the bounds of its machine, otherwise the toolpath usually leaves the bounds of the machine. But if you watch long enough you see it follows the shape I set in my MT Connect machine simulator.

I've also started playing with pulling in other information, like temperature, and displaying that. Right now my simulator doesn't modify the temperature but that should be easy enough. I can see it working where there's a little thermometer shape next to the machine that changes color with increasing temperature. Or even a spindle shape that moves around drawing the toolpath line and changing color with temperature. There's also a power consumption aspect to this all, where maybe I draw bar gadgets next to the machines so you can see at a glance which machines are using the most electricity.

Regardless, MT Connect can provide some very interesting data, but there's a lot of it. At some point the really hard part will be in gleaning out what a user wants to see and only showing them that.

One issue I ran into while building this tool had to do with cross site request issues. An MT Connect agent is basically a webserver, except that it only serves XML strings based on what URL you go to. You can't serve arbitrary files (like JavaScript/HTML files). This isn't an issue if you're writing an application in VB/A, for instance, because the XMLHTTPRequest object provided by Microsoft doesn't care where the request is going to. However, the XMLHTTPRequest does care when it's being called in a web browser. Basically, any AJAX request you send has to be served by the same server that gave you the HTML document your JavaScript is running in.

So to get past this issue (which is a showstopper, if you can't actually get anything out of the agent) I used a PHP script that when called, retrieves /current from the agent, and returns that to the caller, keeping the request on the same domain, as far as the browser knows. So that works well enough, it seems, but it now means anyone who wants to do something similar in the browser has to also have php running (or some server side scripting that can do the same thing).

One other issue I'd like to mention is that I have to use a JQuery library for converting the XML output string of the agent into the JSON format, for creating native JavaScript objects. It'd be very cool if JSON was an option for output on the agent. Maybe that should be something I work on building, and if successful, contribute it to the project and try to get it included in a release.

For now, you can see the veiwer at ccat.us/mtconnect. At some point, I hope the simulated data goes away, and we can start showing the real status of our machines. I'd also like to work at automating the creation of these HTML pages so that other MT Connect users can view their shops using the same code I've written. We'll see where this all goes. In the meantime, I cobbled together another version of the viewer that shows the status of the simulated machine at agent.mtconnect.org as well as the toolpath the spindle is following (right now it only keeps about 20 points, and kinda looks like the game "snake", but I might up that value to show more points.

Contact me at jfournier@ccat.us if you have any questions about this.

Machine Simulator for MT Connect

2011-07-13T09:53:00.007-04:00

In my last post, I talked about how MT Connect works, and how our machine lab isn't yet hooked up to an MT Connect agent (though we're working on it). While I'm waiting for the machines to be connected (and to provide some more lively data) I've created a very basic machine simulator with a fake MT Connect adapter built into the simulation, to provide some action to an agent, ultimately letting me view that action in a web-based tool.

I built the simulator using Microsoft Visio. Basically, I created a fake tool path for a spindle to follow, by just drawing a bunch of node shapes, and connecting them using splines. Then, I created a circle representing the spindle of a machine. The device/spindle shape also holds custom shapesheet attributes mapping device attributes to the device/data item ID's for the machines defined on my agent.

The spindle shape just follows the path of the lines (using a Visio animation routine I built a while back), and at each animation update (set to 2 seconds) it sends our MT Connect agent the current location of the spindle, as well as the current status of the virtual machine (working or broken down). You can see a screen shot of the simulator in action below:

To handle reporting the state of the machine, I just hold a "Next State Change" time on each device object, and on every update see if that time has elapsed. If it has, I flip states (from working to broken or vice versa) and then schedule the next state change event for that machine. Very basic stuff.

I mentioned in my last post that the two agents I've used (available at https://github.com/mtconnect) both allow you to use an HTTP "PUT" request to store information about a machine. So, every time I want to update my MT Connect agent, I just create an XMLHTTPRequest object in VBA (from the Microsoft XML library reference) and open a URL that basically looks like this: http://mtagent/storeSample?timeStamp=(current time)&dataItemID=(data item id for x location, or whatever)&value=(whatever value to store)

With the simulator created, I just set up three device shapes in Visio; one for our Haas machine, one for our Hurco, and one for our Yasda. These machines were already defined in our Devices.xml file on our MTAgent server, which is where our MT Connect Agent gets run from.

By using the simulator to populate data for our real machines, I was able to build a viewer that would dynamically update and show the latest status of all our machines (even though the status was fake). Now, when we get the machines hooked up for real, the same viewer will be able to show the actual status of our machines, which will include a lot more than just spindle X/Y location and if the machine is running or not.

In my next and final post on MT Connect (for the next few weeks at least) I will talk about the HTML/JavaScript viewer I wrote for viewing the current state of our machine lab.

MT Connect Basics

2011-07-13T09:32:00.010-04:00

So CCAT has been tracking this standard/protocol called MT Connect for a while. I've been very interested in it, especially from the standpoint of consuming all this great data that machine shops with MT Connect can generate. I think we're still a long way from having this tool be as ubiquitous as general CNC machining, but I'm hoping CCAT is there with some incredible tools when that does happen (and I think it's inevitable).

So in this post I'd like to talk about how I constructed a web-based viewer for MT Connect data. But first, I'd like to talk briefly about how MT Connect works, as well as how I'm generating data for this proof-of-concept.

MT Connect has been created as a data protocol, and really nothing else. My understanding is that it exists to standardize/define things like: for a milling machine the spindle is where the tool is, and the spindle turns at a rate called SpindleSpeed, and there are certain units that can be measured in, etc... The protocol also defines several key terms: agents, adapters, and devices.

A device is just a discrete unit that can be connected to MT Connect. The most important devices typically are the machines/controllers themselves, but I know the standard involves more than that, including bar stock feeders, tool holders, all kinds of stuff.

An agent is basically a software executable that sits somewhere and listens to things that devices want to tell it. The agent also is able to be interrogated by client software that wants to know things about devices. The agents I've dealt with so far (both are open source and free to use: https://github.com/mtconnect) are implemented using TCP/IP, meaning they work over the internet/web.

The two agents implement HTTP web servers, which allow you to interrogate them using regular web technologies (i.e. the "GET" XMLHTTPRequest). When you interrogate an agent, it spits back your data in an XML file, which is very easy to program for. The two agents I've used also allow you to use HTTP "PUT" requests to store information about devices, meaning you can update an agent even by visiting a URL in your web browser. Very cool, and easy to do.

So, probably the most difficult item here is the adapter. The adapter is what allows a device to talk to the agent. Machine tools typically use their own proprietary protocols and data formats and terminologies within their controllers. A Fanuc controller can put out completely different data streams than a Haas controller, even if they're saying basically the same things.

So an adapter has to be made for converting from one controller "language" (proprietary format/protocol) into the standard MT Connect protocol, and then sent to the agent. So that's the adapter's job. The adapter can live on the controller as a separate piece of software (if the controller allows that) or it can live on a computer that sits near the machine and communicates with it over a parallel or serial cable. Either way, the adapter provides a stream of data about its machine in a standard format.

So CCAT has this Advanced Manufacturing Center where we have a few machines on consignment from Yasda and Hurco, as well as housing our Laser Applications Lab. We want to have these machines hooked up through MT Connect, but we're still working to install the correct adapters for these machines. In the next post, I'll talk about how I built a machine simulator that also acts as an adapter, sending the status of a simulated machine to an MT Connect agent.

MT Connect and CCAT

2011-07-12T16:56:00.005-04:00

MT Connect is a protocol/standard developed for the purpose of allowing machine tools to communicate information about themselves to other computer systems. For instance, this allows a machine to report its current status - whether it's broken down, working, or idle. It can also report its current spindle speed, feed rate, location, and even the current line of g-code that it's running.

All in all, it's a pretty great way to be able to collect activation/utilization data on any machine, regardless of the brand or make or model of controller running it. The obvious upside for simulation users is that you can process the data from a machine and get a list of state-change events and what times they happened at. This data can be run through a distribution-fitting tool, and spit out mean time between failure and mean time to repair distributions. There's a very good paper on this topic here.

The standard is still evolving. Right now it really only covers the machine resources on a shop floor, but at some point I hope it will include labor resources, and part/process tracking. This would allow us to get accurate cycle time/setup time observations on a part-process-machine level, and get us to the point where simulation models can be initialized to the current state of the system being modeled, and then run to predict the next few hours or days or weeks worth of production.

MT Connect can help turn simulation users into basically a weather man, though instead of predicting the weather they're predicting when jobs will be completed and planning contingencies in case a machine goes down. Powerful stuff.

And CCAT is hoping to help make this a reality. We have been attending the MT Connect standards meetings, and I just finished developing a proof-of-concept JavaScript/HTML-based viewer for MT Connect, which I'll detail more in a post to come.

SCL Time Measureme

2011-06-23T11:08:00.004-04:00

Lately I've been working on some models that are pretty involved, in terms of the scale of what's going on as well as making some calls that seem to run slow (creating new parts, packing parts, messing with allocating lists and structures into memory). I wasn't sure what was taking so long, and it's very hard to say with SCL the way it is.

I could have instrumented my code with some subroutine call to store the start time of every subroutine in a logic file, and then another call at the end of the subroutine (before the End line or any Return lines) that logs the time it took to run that subroutine.

Doing so manually would take quite a bit of effort, so I tried my hand at writing something in VB6 that would do the trick, and I think I've succeeded.

I created a standalone executable you can call from any command shell (on Windows) and pass in the full path to the SCL file to instrument, and optionally you can pass a second argument that is the name of the init logic in your model, and an optional 3rd argument specifying a string pattern for commenting out any existing instrumentation you've added to the logic.

Here's an example call I've used:

scltimeinstrument.exe "C:/Delmia/Questlib/LOGICS/CMSD/CMSD.scl" cmsd_model_init_logic *writer(*,*)*

So the first argument again is just the path to the SCL file to instrument. The second argument is cmsd_model_init_logic, so the instrumenter program will find the cmsd_model_init_logic subroutine as it's defined in the file, and the first line after Begin in that subroutine will be a call to a subroutine we include that will initialize the time log file (hardcoded as C:/Tmp/scl_times_log.txt"

The third argument "*writer(*,*)*" specifies to the program to find any line that contains the text "writer(" followed by anything, then a comma, then anything, and closed with a close paren, and finally allow anything outside the paren (to allow comments). This string pattern works well for me because I have one routine called writer where I pass some string message in as the first argument, and the second argument tells what the call means (i.e. error message, or standard debug, or starting/ending some subroutine). So this pattern matches my usage well, because my code is instrumented with this single call, and I can easily wipe out those calls now.

The output file is just a flat text file (saved to C:/Tmp/scl_times_log.txt) that shows the time (in milliseconds) every subroutine call took every time it was called (so long as that time was more than 1 millisecond). It's up to you to analyze the data (I use averageif, etc... in Excel to summarize the data)

Anyways, enough of my blabbing, here's a link to the tool.

Web-based QUEST modeling (using CMSD)

2011-06-09T16:16:00.009-04:00

The form below is a sneak preview of a web-based simulation service I'm trying to develop at the CT Center for Advanced Technology where I work. This form will let you upload an Excel file (example data here) and get a QUEST .mdl file in your email. Just upload the example file and type "ExcelPFA2QUEST" in the "Translation To Do" box below, and you'll get the mdl file.

You can also try this CMSD file. You can specify CMSD2QUEST or CMSD2Results as the translation to do. CMSD2Results will actually run the model and let you view a statistics report online. Or try CMSD2eVSM and you'll get a value stream map showing the data.

To use the example files, you must first download them, and then submit them through the form.

If you use it, please give me feedback using the contact form below.

Due to the formatting issues on this blog, it may be easier to try the form here.
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;br&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;

&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;br&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;

Associative Arrays / Hash Tables / Collections in SCL

2011-04-11T13:38:00.004-04:00

I've been using QUEST for just over five years now, and over time I've become more and more bothered by its lack of a hash table data structure, like I get out of the box in VBA (I know, VBA is pretty ancient stuff itself, but compared to SCL, VBA is a dream, in my opinion.)

A hash table is a data structure is basically a string array that instead of being indexed by numbers, is essentially indexed by strings. In VBA, a hash table is called a Collection, and provides methods for adding, removing, and iterating over its contents. Most implementations of hash tables allow you to put anything in the "bucket" of stuff, keyed by a string.

The purpose of a hash table, as far as I can tell, is to provide a somewhat faster mechanism for finding items in an array than by just looking at every item one by one. Call this the slowest possible case. The fastest possible case would be to just convert a string into a big long binary number, and have a gigantic string array with enough indexes to hold any length string we can throw at it. This is probably the fastest case (I think fetching an item from an array is done in constant time), but it's not really feasible, especially with QUEST SCL, because we don't have all the memory in the world to hold this huge array, which, by the way, would be pretty much empty.

So enter the hash table. According to the Algorithms in C++ book I picked up at the library book sale for 75 cents, we can instead create a small array, with each array space holding a linked list of items with a specific hash value. The linked lists are there because we know that by limiting the size of our array, we can have different keys with the same hash.

The idea then, for searching for a key value, is that you hash the key and get a number between 1 and 111, and get the base node in the linked list at that array index. Then, we just search through each of the nodes in that linked list until we find our exact key value, and return the original string.

This kind of thing seems pretty easy to pull off with SCL, as it's just a matter of providing the hashing function (nicely included in the book), and a way to hold an array of linked lists for each of our 111 possible hash values.

I've put together a hash table utility in SCL, though I called it a collection. It's available for download here with an example for using it here. I put the hash_table.scl file into my directory of always compiled utility routines.

To use the hash table, you have to include the SCL file (I had to specify the full path to the file, so you'll have to modify that to accommodate your system. To create a collection, call the new_collection routine, which initializes a collection structure. Use col_add to add an item, remove_item_from_collection to remove an item, and col_item_exists to check if there is an item in the collection already. The kill_collection procedure will deallocate all the memory for the collection, so make sure to call that when you're done with it, or you could end up eating a lot of memory, depending on how you use this.

Another note, you can loop through every item in the collection, starting (assuming you call your collection col) and looping through a linked list of every item in the collection.

I haven't tested it terribly well, but the example file seems to work as I intend, so unless I start using it and find it broken, this is how it'll stay.

I'm not sure how much faster this is, computationally, than just looping through each item in an array and checking it. It's probably a little slower for small collections, but I imagine as the thing grows the hash table becomes faster than just looping, but I don't know. I do think it'll make some lookups a bit easier, at least from a programmer's productivity perspective, but then again, what do I know? Either way, I'll have to try and implement more of these algorithms, especially the section on regular expressions.

Labor Popups (or, Demystifying the Labor System in QUEST)

2011-03-10T09:12:00.005-05:00

Labor logic can be really difficult to understand without first getting the proper grounding in just what's going on. I was lucky enough to get some training from Martin Barnes at DELMIA, who stepped me through the entire process, including how popups play into things.

Basically, the labor system uses a controller to select a labor to fulfill some request, then it passes information about the request through a command. The labor then picks up the command and acts on it. This seems simple enough, but reading through the code it doesn't seem so straightforward, as you can't see the labor actually doing anything. This is because of popups.

Popups in QUEST allow a user to write incredibly flexible (reusable) logics at the expense of readability. In the default labor process logic, you can see the labor just constantly sits there getting the next pending command to work on, and then does a switch block to see what kind of command it is. It then gets a handle to the popup it should use to execute the command, and runs that popup.

So in the case of laborers, a popup is simply an object that lets us run some SCL code without knowing ahead of time precisely which SCL routine/procedure to run. You just query the popup that a user has selected, and run it, and assume that logic is taking care of business.

When we apply this thinking to the labor system, it demystifies things a little bit (at least for me). The regular labor process logic then becomes fairly simplistic...do a switch against the command type, and based on command type, get a handle to the logic to run, then run that logic.

The real meat of the labor logics, and the thing that kept me from understanding how they work, is in the default popup implementations.

In the labor Logics window in QUEST, you'll see a few options beyond the regular process and init logics. These are all popups, just a way of selecting a procedure/routine that's going to get called in the default labor logics. So to see what these default selections look like, we can just look at a labor's properties and see the routine names and file paths for the selected popups. The default labor load popup is notify_after_all_loads and can be found in QUESTlib\SYSDEF\LOGICS\agv_load.scl.src.

If you load that file up in an SCL editory, you can see the notify_after_all_loads is a procedure that takes an agv_cmd handle (agv's and labors are pretty similar, you can see, by digging into their logics. My understanding is laborers were essentially copied and pasted from agv's, back in the day at Deneb. Old/ex Deneb people can be dangerously misleading, but interesting nonetheless).

The flow of this logic is much much more readable than the labor process logic, again, because this is where we actually DO stuff. So here we can see that we do load processes if necessary and all that, but eventually we just do a REQUIRE PART EXACT the_part, where the_part is just a handle passed in as cmd->part_handle.

The interesting thing about this line of code is that it's the same thing a machine element uses to get parts (or buffers, whatever). If you look at the unload popups, you see it's just transferring a part to whatever element it's at. There is nothing the least bit magical or mystifying here. In fact, this makes the labor system seem to make a lot of sense.

This may have been obvious to you, but I was never able to get a handle on this until someone walked through the whole thing with me. I know I can't do as good a job as Martin did, but I hope this gives newer QUEST users who don't know the labor system the ability to go in and see just what's going on. Ever since I "saw the light" on how this all works, I've been able to write my own labor controllers and labor logics. With that understanding comes the ability to get very detailed control of your labors, as well as the ability to write some really really bad code. Be careful.

Here's a quick example of a custom labor load popup I recently had to write. The labor would load a part and immediately destroy it, with the controller having already gotten what it needs from the part. Keep in mind I'm using a custom controller, so I don't need to notify the controller that the labor destroyed the part. Your mileage may vary.

procedure custom_labor_load_popup( cmd : Agv_Cmd )

Var

the_part : Part

Begin

the_part = cmd->part_handle

require part exact the_part

destroy( the_part )

End

Hand-Drawn Value Stream Map

2010-12-21T14:28:00.005-05:00

Sometimes I get ideas where I can't really let go of them, until they're realized. These ideas tend to be stupid, useless, or impractical, or any combination of the three. I probably would do better to just let these things go, but to this point I've only been able to just implement the idea and move on (case in point).

Here's another stupid idea I couldn't let go of: making computer-drawn value stream maps look hand-drawn. It was a concatenation of circumstances that made me implement this; namely, I saw a post on a Visio blog on making shapes look hand drawn.

So I wrote a VBA macro in Visio that takes an eVSM map and makes it look hand drawn. I implemented this and moved on, like I feel I should. But recently, I saw a post somewhere linking to a whiteboard font based on the t.v. show House, and decided I couldn't live without seeing how it my "hand-drawn" maps would look with a "hand-drawn" font to go with it.

Here's a regular eVSM map:

And here is one of my "incredible" hand-drawn maps, rendered like on a whiteboard (minus any smudges one might expect):

I guess my point for sharing this was just to, 1, show off a really stupid little trick I somehow couldn't live without, and 2, to say that sometimes you have to just give up and give in to that part of your brain that thinks "wouldn't it be cool if...". Who knows, it may come in handy some day (and I mean the experience of working through that problem).

Winter Sim Presentation (2010)

2010-12-09T13:14:00.003-05:00

I saw some cool presentations at Winter Sim this year. One vendor presentation that stood out for me was from forio.com, which lets you upload simulation models and run them in the cloud. Very cool.

I also gave a presentation with Swee Leong from NIST:

Bitwise Comparison

2010-11-08T14:09:00.005-05:00

Say you want to have a routine in QUEST SCL that may have to do some things and not others, or vice versa. One way you can specify what sections of code to do is have a series of "flag" that tells the routine what to do and not do. Each flag controls one aspect of the code.

One place I can use this kind of control is in a routine for writing debugging messages to a text file, and optionally to the screen. So for one of these routines, I'd probably want a flag saying whether or not to write to the screen, and another to specify if it's an error message (in which case write to the screen and ignore the other flag), and maybe two more for telling the routine when I'm entering a routine and exiting a routine (to keep track of the call stack, so to speak).

So in this case, I'd need to have four flags I'm setting to true or false every time I call this writing routine. And, if I want to add another flag, I have to change all the calls I've made to this routine to match up with the new flag, since SCL doesn't give you the ability to add optional arguments.

So, rather than deal with this issue of having a flag variable for each option I want to add in a routine, I can instead take advantage of the nature of binary numbers in the computer. Before I continue, keep in mind that I didn't major in computer science or computer anything, so my explanation will probably sound hokey and not quite right.

A computer deals with numbers using binary, where we have a set of numerals that can have a value of zero or one. Each numeral you add on adds a power of two (rather than 10 like in our base-10 system). So, for instance, 1 in binary comes out to 2 to the power of 0, or 1. 10 in binary comes out to 0 to the power of 0 (0) plus 2 to the power of 1 (2) = 2. 100 comes out to 0^0 + 0^1 + 2 ^2 = 4. 1010 comes out to 0^0 + 1^1 + 0^2 + 2^3 = 10

Hopefully, if I did that right, you'll see a pattern where each digit we add onto the left adds another power of 2. 1 = 1, 10 =2 , 100=4, 1000=8, 10000=16, and so on. By seeing this pattern, we can also see that we could use a binary integer to store a series of yes/no flags using 1 for yes and 0 for no (or whatever you want). For instance, 2 + 8 in base 10 equals 10 + 1000 in binary or 1010.

The practical upshot of all this so far is, we can now create a series of flags, each unique flag being a power of two value (1,2,4,8,16,32, and so on), and we can store all the flag values we want to activate by adding the ones we're using together.

So, to define our constants for our message logger:

WriteToScreen 1

ErrorMsg 2

EnteringRoutine 4

ExitingRoutine 8

If we want to write that we're entering a routine we'd just pass in WriteToScreen + EnteringRoutine, which would calculate to 9 in base-10, and our routine could then know which flags to activate based on that number 9.

Now, to break that 9 back up into its parts, we need to go backwards and turn a decimal number back into binary 1's and 0's. Following is a routine that'll do that for us. I'm not sure it's the most efficient, but it seems to work. It works by reading left to right in the powers of two (starting at power 8 - you could increase it if you have more flags to handle). So it starts and sees if 2^8 (256) is less than the num we're trying to break apart. If it is, we turn that flag to true, and subtract 256 from the number until we get down to the last power. In this routine we pass in the flag we want to check against, and return true if the bit we're looking at is true.

Hopefully I didn't bungle the explanation too much, but I really just wanted to have this routine up for future reference, and hopefully it gets you thinking of ways it can help you write more concise or powerful code in SCL.

routine bitwise_or( num : Integer ; against : Integer ) : Integer

Var
 i : Integer
 pow : Integer
 sum : Integer
 result : Integer
Begin
 sum = num
 for i = 8 to 0 by -1 do
    pow = 2 ^ i
    if( sum >= pow ) then
       sum = sum - pow
       if( pow == against ) then
          result = true
          break
       endif
    endif
 endfor
 return result
End

GetTickCount

2010-10-25T22:04:00.005-04:00

Tonight I was trying to debug some slow SCL code, and wanted to pinpoint exactly which routines were taking the longest to execute. QUEST has a systime() routine that returns the number of seconds since midnight. However, I wanted more accuracy, so I needed to use the GetTickCount routine provided by the Windows API.

I can call this routine using C_EXEC in SCL, and the final routine comes out like this:

routine get_tick_count() : Integer

Const

THE_DLL 'kernel32.dll'

THE_CMD 'GetTickCount'

Var

func_return : Integer

Begin

func_return = c_exec( THE_DLL + ":" + THE_CMD )

return func_return

End

Now, I can get a bit more visibility into what's taking my logics so long to run (though be sure to disable any calls to this routine once you're ready to just run the model)

Select a Part

2010-10-15T09:49:00.004-04:00

The other day I was working on a project where I wanted some stats on a part in a model that don't show up in the Trace Entity window. So, I went to write a macro that would let me select a part and show the information I needed. I then realized that I didn't have a routine available that would let me easily select a part, so I went about writing one. Now, it's available for download here, because it was a pain to write and now you don't have to write it too.

eVSM and QUEST User Groups

2010-09-09T14:46:00.003-04:00

If you read back to past posts on this blog, you'll see I do a bit of work with eVSM. Up until now, there hasn't been any organized group of eVSM users that I know of, but that's now changed. An eVSM user has started a LinkedIn group geared toward discussing eVSM, as well as how to do various things in eVSM. You have to be a LinkedIn member to join, and then you have to search for the eVSM user group. Honestly, it would be nice if we could get enough eVSM users on board to build an eVSM Stack Exhange site.

I'm hoping this community gets enough power users and casual users to build and sustain some decent conversation. Luckily, the QUEST group I set up seems to have a great core of power QUEST users (including past & current Deneb/DELMIA employees) who are able to give advice and tips on how to tackle specific problems in QUEST.

Hopefully we can say the same for the eVSM group, soon.

eVSM to QUEST Beta Version Now Available

2010-08-18T16:26:00.004-04:00

Any QUEST users interested in trying our (CCAT's) eVSM to QUEST converter may now do so, if they'd like to participate in beta testing (meaning we're not sure how well it works yet on lots of different computers). So if you'd like to try it out, email me at jfournier@ccat.us and let me know.

This requires you at least have access to QUEST and Visio (you'll have to get a trial version of eVSM)

Also, more information here.

IE Stack Exchange Site

2010-06-18T08:56:00.002-04:00

I recently advocated anyone reading this blog check out OR-Exchange. Basically, the case is/was that if OR-Exchange didn't get to a certain amount of web traffic it would be shut down, as the people behind it (Stack Exchange) have a new model where they want to create nice, high volume question and answer sites on any topic people are willing to discuss.

I've been thinking about it, and it's my opinion that OR-Exchange may be a bit too niche to be able to attract enough users to keep alive.

So I am proposing we create a Stack Exchange site on Industrial Engineering/Continuous Improvement/Systems Analysis, whatever you want to call it.

If you're interested in seeing this site come to fruition, visit:

http://area51.stackexchange.com/proposals/6949/continuous-improvement

and follow the site, and if we can get enough followers and example questions, we can move on and get a centralized, modern community started for discussing anything IE/OR/CI.

Number Rounding in SCL

2010-06-01T16:24:00.002-04:00

I recently found the need to do some simple number rounding in SCL, and was able to dig these two routines out using my SCL Subroutine Indexer though the index was from a previous computer I used, and hadn't copied over to my current machine. Thankfully, Google Desktop was able to find a backup copy I had made who knows when. So, to prevent me from losing these simple functions forever, here they are.

Nothing fancy; I round a number down by converting it to an integer string, then reading it back to a number using VAL. I guess SCL will truncate a number at the decimal point when converting to an integer string (%g), rather than do any real rounding. So to round up I just round down and add one. Like I said, nothing fancy, and apparently nothing worth searching for 20 minutes over. Anyways, these would be good to keep compiled all the time.

routine round_down_to_int( num_value : Real ) : Integer

Var

int_string : String

result : Integer

Begin

result = 1

int_string = str( '%g' , num_value )

result = VAL( int_string )

return result

End

routine round_up_to_int( num_value : Real ) : Integer

Var

result : Integer

rounded_down : Integer

Begin

return round_down_to_int( num_value ) + 1

End

eVSM, CMSD, and ProModel

2010-04-22T14:56:00.001-04:00

So here's a video showing the new ProModel translator I wrote for CMSD. It also shows a little bit of the CMSD Viewer program I've been working on. Best watched in HD so you can read the text and follow along...

Core Manufacturing Simulation Data

2010-04-22T11:19:00.003-04:00

I'm not sure if I've mentioned this yet, but I'm pretty sure I haven't. A little over 3 years ago I attended Winter Sim 2006 in Monterey, CA (nice place by the way) and got introduced to the Core Manufacturing Simulation Data (CMSD) specification from NIST. This spec was supposed to act as a neutral data format for holding manufacturing simulation.

I watched its progress over the years, hoping at some point to be able to apply some of my past work translating Value Stream Maps into QUEST models to be generically available to any simulation package.

Cut to March of 2009, and it seemed like the spec was getting pretty close to being a standard. NIST had the spec in to SISO for review and eventual vote, and my boss saw a presentation by Swee Leong from NIST, and was impressed enough by it to allow me to start working on a CMSD translator for Value Stream Mapping.

So I got started right away, first stepping back and looking at what this translator should be. I should mention that the CMSD format is technically set to be a UML standard, but along with that will come an XML schema. So anyways, long story short, I hadn't done much work with parsing XML files, and had some experience kludging together solutions to build XML files, and didn't like the idea of implementing a parser/writer for each translator I might write.

So I decided to build a centralized CMSD XML parser/generator, utilizing Microsoft's built-in DOM libraries to do the actual file I/O from/to XML files, and I would write the code to translate XML elements into instances of CMSD classes. So I built that central tool as a COM/ActiveX class, using VB6 (I know, could I possibly use something older?). So to read a CMSD file I just have to create a new CMSD object and tell it to read the file, and I get all the CMSD data in a nice, easy to program against object model. And, I only have to write and maintain one XML I/O code base, which makes me happy.

So I called this class the CMSD API (very original, I know) and started writing translators. To cut my teeth on the standard, I started off just building something to build a QUEST model from a CMSD API object, just using a simple XML file that NIST had provided to me to demonstrate the XML format. That one translator has turned into about a dozen different translators, some proofs of concept, and some potentially useful tools.

So here, after six paragraphs, is where I get to my point. We're reaching the stage where these translators are ready for some public consumption. They're hopefully useful enough that people can use them, though because the CMSD standard isn't really set in stone yet, I'll refrain from calling them CMSD-based tools; rather they're just tools that utilize a custom XML format.

Okay, so seven paragraphs in, and my point is that I'm looking for simulation users interested in trying this software out. I can't guarantee I can take everyone, and ideally you should be a user of more than one of the following tools:
1. DELMIA QUEST
2. eVSM
3. ProModel
4. Arena
5. Excel
6. Simio
7. FlexSim

Now, if you only use one of the above-listed simulation packages, that's okay. I've also been working on a standalone CMSD editor, that hopefully in the future can take the place of a simulation package builder interface (and just use the simulation package as a solver). Also, if you're good at programming in VBA and would like to be able to build your own translators with my CMSD API, let me know, as I'd like to get feedback on the quality of the methods in the API.

So if you're interested in joining a beta test, contact me. In the meantime you can see the documentation for these tools grow as I write it (thank you, Google Docs):
Documentation

OR Exchange

2010-04-15T16:27:00.004-04:00

I've been a member at StackOverflow since it launched to the public. For those who don't know what it is, it's basically a question and answer site built the way a question-answer site should be built; namely, every page deals with questions, and answers (rather than traditional forum type sites, which are more for threaded discussion, but get question-answer sits shoehorned in). They've built a fantastic community, which means you can go on there and ask a programming question and get an answer in a pretty respectable amount of time.

About 6 months ago they launched StackExchange, which was a service that let people set up their own question-answer sites, with the same look and feel as StackOverflow, but you were responsible for getting your community in order. Apparently a lot of the sites that were created never really got going very well, and that's led the StackExchange people to change the rules a bit. From now on, if you want to start a StackExchange site, you have to put together a proposal convincing them why they should build it, and then you have to rally enough users to initialize the site with questions and answers, and hopefully get enough momentum going that they can launch your site and you end up with a community where you can get answers to your niche questions.

The point of this post, then, is to talk about OR-Exchange. OR-Exchange is a StackExchange site built for answering Operations Research problems, which involves a lot of math programming, but simulation is definitely a part of that. Unfortunately, the StackExchange people don't seem to think there's enough participation in the site, so it's got 3 months left before it's shut down (we'll call it early July is the termination date).

So I encourage you, if you're a simulation user (and why wouldn't you be if you're reading this, unless you're my mom (who doesn't read this, by the way)) to visit OR-Exchange.com and join the community, and maybe ask some general purpose simulation questions (if you know the answer, you're allowed to answer your own questions, too).

Interpreting BCL Error Codes

2010-03-31T10:12:00.003-04:00

From time to time I'll have to write an SCL macro that executes some BCL statements. It's usually pretty straightforward, just issue the command using the BCL() function in an SCL macro, and it'll return a numeric error code, including 0 for a normal return.

Sometimes though, especially when working with user-provided data, these commands can fail (often due to invalid characters or some such thing). When a BCL command fails, the BCL() function returns a non-zero number and an error message gets printed to the screen for the user to see.

However, a lot of the SCL macros I write are run pretty much autonomously, so anything printed to the screen gets lost to me. That's why I usually have a function for logging messages to a text file, for analysis after the fact, to see why some macro failed.

So, getting to my point, finally, when I am using the BCL statement, I like to have my own routine (named exec_bcl_cmd or something) that wraps all this stuff together: executing the BCL statement, evaluating any error code return, and logging that to a text file. I've created an example SCL file that shows most of this, just a procedure named exec_bcl_cmd, that executes a bcl statement string, then converts the bcl return code integer into a more descriptive error message (pulled from the bclerr.inc file).

You can download it here.

Name Change

2010-03-24T15:30:00.002-04:00

If anyone even reads this to notice, I've changed the name of this blog from just DELMIA QUEST to DELMIA QUEST and Manufacturing Simulation. I did this because, for the last year or so, I've been dedicating a lot less time to QUEST than I previously did, and a lot more time on using Value Stream Mapping for building simulation models, as well as some other production design/analysis tools.

I'm going to continue focusing a lot of content ("a lot" is used loosely here meaning there's not much content to this blog anyway) on QUEST, but I also want to be able to talk a bit more about the other stuff I do, and a lot of that applies in some way to QUEST, ultimately.

How to Populate a Value Stream Map with Simulation Data

2010-03-24T14:26:00.010-04:00

So if you look back in the archives of this blog you might see I've done some work taking data from Value Stream Maps (VSM's) and using it to build QUEST models semi-automatically. With pretty much any simulation package, a user is presented with an interface that exposes pretty much every option imaginable. With VSM, a user only tacks on the data they have available. Some people get overwhelmed by too many dialog options at once. In essence, when you're building a VSM with the intent of using it for simulation, you're only sticking in the data you have, and ignoring all the other options you don't have information for, with a much simplified interface (the VSM software).

It's also important to note that there are two different world views for manufacturing simulation packages, really, that I've seen: resource-based, and process-based. In a resource-based world view, you see all your machines on a virtual floor with some labor objects, maybe. Parts or whatever you call them enter at a source and jump around machines and modeling elements corresponding to, for the most part, physical objects. A process-based view is different, in that you basically get a flow chart where each block usually represents a process or a decision or something. The part item arrives at a source, again, but now moves between processes in sequence through the flow chart. A process can require different resources, so that parts end up getting blocked like in real life. Essentially both world views contain the same information and provide the same outputs, but just go about getting the outputs in different ways.

I'll tell you right now that a VSM pretty much takes on a process-based world view, except that people usually name their process boxes after the resource where the process is done. So there's sort of an implicit definition there, saying that we're doing a process, and that this process requires a resource based on the name of the process.

You may or may not know about QUEST's world view, so I'll go over that quickly: it's a resource-based view, with a construct called a "process" that holds attributes on the process, like what labor resources it requires and what the cycle time is and all that. There is also a "part class" construct that holds some attributes, including the sequence of processes the part needs to be "completed". A machine in QUEST can be told what processes it's able to perform, so that when a part arrives at it, it decides what process to do on that part, and we can then route the part on to its next process (whatever machine that may be at).

So a few years ago a client presented us with a VSM they had created that detailed the process flow for a line they wanted to simulate. It contained some cycle times, but it was, otherwise, pretty much just a process sequence.

So I had to figure out, how can I take this information in an eVSM file (which has an automatic export to Excel) and turn it into a QUEST model. It was pretty easy to just do a one-to-one build of processes in QUEST; one process for each process block in the VSM. But the missing component of data, then, was how to tie a process to one or more machines in a QUEST model?

To tie a VSM process to a QUEST machine resource, I simply had to add a tag onto a process with the ID of the machine to attach it to (a many processes to one machine relationship). So the actual SCL code to do this consisted of reading through the Workstation column in the Excel file, and for each unique value in that column, just build a machine with that name. Then read through every process (row) and create a process in QUEST with that name. Then, look at the Workstation column for that process row, and assign the process to that machine (the Workstation value can actually be a comma-delimited list to specify that multiple machines can handle the process).

The next challenge was process sequencing. I could have assumed that the Excel output from eVSM was in order of the process sequence, but that'd be pretty limiting to a simulation user. eVSM requires that you provide a tag shape to each process shape, and the tag value must be unique for each process. So, I required that the sequence be encoded through just specifying a process' next operation in the sequence (using that next operations' tag text) as a process attribute. Then, the SCL to build the QUEST model just has to set the process sequence for a part class to the sequence of operations in that Excel file. This way of creating the sequence also allowed me to look at each individual process, and find whatever processes were feeding into it. So if I found two or more processes that both output to a single process, that single process must be an assembly operation, and require a part from each of them before running the process.

That brings me to my next, and final data requirement: the part type. Like I said, QUEST likes to have a part class for each unique part type in a system (there are exceptions of course, but I won't get into them). Each part type (in the type of model we're building here) should then have a sequence of operations for the purpose of routing and process execution. So to specify the part type for a process, I just required there be a Product attribute on each process, and the SCL chunks through the data and identifies the sequence of operations and assembly points and all that automatically.

But, to close out, we really need three pieces of information to successfully build a (however basic) QUEST model: what are our part types, what are their process sequences, and where do those processes get done. And a VSM is perfectly adequate at providing that information. I meant to be a lot more succinct in my explanation of how the conversion works, but I'm not sure it's possible. I'll give it a shot again some other time.

Winter Sim Presentation

2010-02-18T12:57:00.001-05:00

This past December, I was fortunate enough to be able to present some of the work I've been doing with extracting data from Value Stream Maps and turning it into simulation data. I started off using QUEST as the simulation tool for the data, and last March (2009) I got the green light to start working on implementing the Core Manufacturing Simulation Data (CMSD) format. The CMSD is meant to be a generic simulation data interchange format, sort of like STEP is for CAD.

So, here's the presentation I made at Winter Sim. If you want to talk about it, you can contact me here.

Labor shirt colors

2010-01-20T15:16:00.006-05:00

This is a stupid, however somewhat useful SCL macro. Sometimes I end up with a model with lots of laborers who all have the same color shirt. Call me crazy, but I think the model presents a little better if the labors don't all look the same.

So here it is, a stupid SCL macro you can use to change all your labors' shirt colors (note it won't let the color be the same as his pants or skin color (at least with the default laborer I'm using))

So here it is

SCL Examples

2010-01-20T14:57:00.002-05:00

I recently received an email from a student using QUEST who was looking for examples of SCL.

I told him to first look at the default QUEST logics at QUESTlib\Sysdef\Logics, to see how QUEST uses SCL.

But I can't think of any good examples of how to write SCL macros. So I found an old macro I wrote that dumps all the process assignments for each laborer in a model to a tab-delimited text file. I figured it would be a good example of how to use SCL to get information out of a model, and shows some examples of different SCL syntax.

You can download it here, hopefully; I put it on Google Docs as just a file, so you should be able to go download it there.

Examples of using C_EXEC in SCL

2009-09-01T09:03:00.003-04:00

SCL provides a function called C_EXEC which will allow you to execute functions in Windows DLL files. If you have used the Declare Function ... functionality in VBA then you'll see this is the same kind of functionality.

Basically, to use C_EXEC you need to know the name of the function in the DLL file, as well as its argument list. For example, the Sleep function resides in the kernel32.dll file that comes with Windows. It takes one argument, which is the sleep time in milliseconds. This function simply delays for the specified period of time, then returns control of the program back to whatever called it. This allows you to put a pause of whatever length you want in your program.

Since there is no built-in sleep function in SCL, this is a good function to have handy, always compiled and ready to use.

The syntax for the C_EXEC function is simple:

C_EXEC( routine_name_and_location , arg1 , arg...)

where routine_name_and_location is the dll filename and function name separated by a colon (:). Any extra arguments to C_EXEC should correspond to arguments in the DLL function.

So for the Sleep function, a C_EXEC call would look like this:

C_EXEC( 'kernel32.dll:Sleep' , 1000 )

Calling this in SCL would make your SCL code delay for 1 second.

We can wrap this in a nice routine that you can leave compiled all the time:

routine sleep( milliseconds : Integer ) : Integer

Const

THE_DLL 'kernel32.dll'

THE_CMD 'Sleep'

Var

func_return : Integer

Begin

Public Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

func_return = c_exec( THE_DLL + ":" + THE_CMD , \

milliseconds )

return true

End

Here's another example using the mciSendStringA function in winmm.dll to open your CD drive door (I know, very useful):

procedure open_cd_drive()

Const

THE_DLL 'winmm.dll'

THE_CMD 'mciSendStringA'

Var

func_return : Integer

lpstrCommand : String

lpstrReturnString : String

uReturnLength : Integer

hwndCallback : Integer

Begin

Public Declare Function SendCDcmd Lib "winmm.dll" \

Alias "mciSendStringA" ( \

ByVal lpstrCommand As String, \

ByVal lpstrReturnString As String, \

ByVal uReturnLength As Long, \

ByVal hwndCallback As Long) As Long

lpstrCommand = 'set CDAudio door open'

lpstrReturnString = ''

uReturnLength = 127

hwndCallback = 0

func_return = c_exec( THE_DLL + ":" + THE_CMD , \

lpstrCommand , \

lpstrReturnString , \

uReturnLength , \

hwndCallback )

End

Hopefully this gives you a good taste of what is possible with using C_EXEC to extend some of the functionality of SCL beyond what's currently available. If you want to see how you can create your own Windows DLL (and thereby provide your own custom functions in a compiled form) you can look at this web site. At some point in the future I hope to release a DLL library of functions to help add some functionality to SCL.

Converting SketchUp models to QUEST pdb files

2009-08-31T08:19:00.004-04:00

SketchUp is a 3D modeling tool which was originally developed by @Last Software, which was purchased by Google. Google now provides the SketchUp tool for free, to encourage modelers to create real-life geometry for its Google Earth tool, as well as populating their 3D Warehouse, which is a huge repository of 3D models.

SketchUp is very easy to use, easy to learn, and very powerful for being a free tool. It's much easier to use than the QUEST CAD world, though the free version of SketchUp has some limitations which make it difficult to get SketchUp models into a format that QUEST will recognize. The free version will only export to the Collada format, which is not supported by QUEST. This means you have to use some intermediary program that can read Collada files and export to something QUEST understands (i.e. VRML 1.0, DXF, OpenFlight Obj).

Until now, the easiest way to get from SketchUp into QUEST was to shell out $495 for a license of SketchUp Pro, which includes a DXF exporter.

I say until now, because luckily the Guitar-List.com website has put together a Ruby plugin for SketchUp that exports from SketchUp to DXF, for free.

That's only half the battle, so with permission from Guitar-List.com I was able to modify their script to use QUEST's built-in DXF to PDB conversion tool so you can automatically export from QUEST to DXF to PDB.

You can download the ruby script here. Download it to your Program Files/Google/Google Sketchup/Plugins folder.

One pre-requisite for this script to work, however, is that you must have your dwg2pdb.bat file configured so that DENEB_PATH is set to whatever your Deneb or Delmia path is. You also must set the DENEB_PROD_DIR to point to the quest folder (default was vmap for me) and make sure LM_LICENSE_FILE is pointing to the right place. These settings should more or less mimic some of the settings from your quest.bat file.

Next copy the dwg_cmd file from your quest folder to the bin folder, and set your default units to inches.

The last thing you'll have to do is edit line 64 of the skp_to_pdb.rb file to point to your dwg2pdb.bat and dwg_cmd files.

It may take a bit of work to get set up, but I've been using it for a few weeks and it's nice to be able to use a modern 3D drawing tool and easily load the geometry in QUEST.

A few notes on usage, make sure you draw to the proper scale in SketchUp, and be mindful of the origin. If your geometry is far from the origin in SketchUp it'll be far from the origin in QUEST, too.

Again if you want to contact me directly just hit me up here or leave a comment.

How to run QUEST from Excel VBA and wait for QUEST to finish

2009-08-25T15:09:00.004-04:00

This post is not meant to show you how you can use VBA to run BCL commands in QUEST. It's just a small tweak to how we run QUEST in this previous post. In that previous VBA solution, I used the baked-in Shell command to run a QUEST.bat file in BCL mode.

One reason I can think of for using this functionality is being able to automatically run some experimentation in QUEST, without having to mess with sockets (until we can get an easy to use library for QUEST sockets). This way we can have some Excel worksheet with accompanying VBA code that will run QUEST, wait for QUEST to exit, then check some output file from QUEST before advancing in the experiment. I am working on a project where this is pretty much exactly what I'll be doing.

To make this work, we just need to use a different Shell command, that will effectively halt execution of our VBA code while QUEST runs, and resume execution once the QUEST process we started ends.

Basically, we will re-use the code found here to replace our basic Shell call. All the linked code does is start QUEST using the Shell command, and uses a few Windows API calls to monitor the QUEST.exe process we started, looping until that process ends. Once the process ends, we exit the loop and VBA continues executing code.

I've updated the QUEST_BCL_Addin.xla file which can be downloaded here to include this new ShellAndWait functionality. If you call the SaveABCL function with LaunchQUEST = True and TransferToMenu = False then your code will wait for QUEST to exit before resuming.

I'd like to start adding some QUEST BCL User Defined Functions to this addin in the near future. I have some written already, but would like to get them properly formatted for release. If you have any you'd like to donate drop me a line using this contact form.

Split function in SCL

2009-08-25T09:56:00.009-04:00

VBA has a function called Split that is handy for parsing strings to an array based on some delimiter.  All you have to do is dim out an array variable and say:

ArrayVar = Split( "the,split,string" , "," ) and your ArrayVar will contain three strings, "the" , "split", and "string".

There is no in-built function in SCL to do this, so I have put together something that should work in a similar fashion.  I have named the function the same, though the difference here is because SCL's arrays are fixed in size, where with VBA you can dynamically size arrays.

To get around this, you must first declare a String array in the Var section of your calling procedure (or globally), and pass that into the Split function as the last argument.  You must also provide the upper bound of the array to the function.  This upper bound is not the highest index of the array (which is one minus the size of the array), but just the size of the array.  One easy way to use this information is to declare your arrays using Const's denoting the size of the array.  For example:

procedure some_proc()
Const
arr_size 10
Var
my_array : Array[ arr_size ] of String

........

So, in this case, if you wanted to split a string into my_array, you would do this:

num_elems = split( 'some delimited line' , ' ' , arr_size , my_array )

where num_elems is the number of chunks of text split into the array.  If there are more chunks than there are bins in your array, any trailing chunks will be ignored, and no error will be raised.

I have tested this routine a bit, so it should work fairly well, even with multi-character delimiters.  On a side note, you should put this routine into your always available routines in QUEST.


routine split( the_line : String ; the_delim : String ; max_elements : Integer ; Var the_array : Array[] of String ) : Integer
Var
   write_idx , delim_idx : Integer
   check_char : String
Begin
   while( len( the_line ) > 0 ) do
      if( write_idx < max_elements ) then
         delim_idx = index( the_line , the_delim , 1 )
         --write( 'delim_idx=' , delim_idx , cr )
         if( delim_idx > 0 ) then
            the_array[ write_idx ] = leftstr( the_line , delim_idx - 1 )
            the_line = rightstr( the_line , len( the_line ) - delim_idx - len( the_delim ) + 1 )
         else
            -- no more delimeters left - write the last of the_line to the array
            the_array[ write_idx ] = the_line
     the_line = '' -- empty the_line so we break from the while loop
         endif
         write_idx = write_idx + 1
      else
         the_line = '' -- empty the_line so we break from the while loop
      endif
   endwhile
   return write_idx -- return number of pieces written to array
End

Evaluating string expressions in SCL

2009-08-18T15:06:00.005-04:00

I have found a few cases where it would be better to allow a user to enter not just numbers, but some expression that can be evaluated to a number. An simple example of this is just evaluating calculations, like "10+2*(8/5)". Ordinarily, if someone entered this and you were expecting a number, you may have a real problem. But luckily QUEST provides a means for evaluating strings to Real values, or even to String values.

The method involves calling out to BCL to evaluate an SCL expression, returning either a String or Real value. The associated BCL commands are SCL_NUMERIC_EXPR and SCL_STRING. You just pass in the SCL expression and read the resulting BCL_MSG variable as the result.

Here are two SCL routines that make these BCL commands a bit easier to use:

BCL_VAR

bcl_msg : String

routine evaluate_scl_expr( the_string : String ) : Real

Var

bcl_err : Integer

Begin

bcl_err = bcl( "SCL_NUMERIC_EXPR('" + the_string + "')" )

return val( bcl_msg )

End

routine eval_scl_string( the_expr : String ) : String

Var

bcl_err : Integer

Begin

bcl_err = bcl( "SCL_STRING_EXPR('" + the_expr + "')" )

return bcl_msg

End

Quest_Geom

2009-08-04T11:54:00.001-04:00

I've used the same solution Martin described, and clumsy is an understatement, but it has worked fairly well for me in the past. From what I've seen of the format, it's similar to the wavefront obj format, if that helps...

Here's an overview of how a basic QUEST geometry file is laid out, just from my messing around with these files...I have no expertise in how the format works, this is all based on observation and guesses.

All these observations are based on a basic rectangular block I created in QUEST D5R18.

Basically the file starts with the number 12, probably a version number or something, then some vector transformation information, probably for locating and rotating the geometry, though I've never messed around with that. After all this information there is an asterisk indicating the geometry section is beginning. I've found that older geometry files don't have this asterisk to delineate between geometry sections.

For a basic rectangular box, there are 8 points, for each of the 8 corners on the box.

After the first asterisk, there is a number indicating the number of points in the geometry. Points serve as vertices for lines. After listing the number of vertices, you list out the xyz location of each vertex.

After the vertices you list out something, and I either never knew or forgot what it is, but the geometry I'm looking at now has a zero.

Next we indicate the number of and list out all the lines in the geometry. So if we have a rectangular box we have a total of 12 lines, as you can see in the diagram below.

To describe a line, we have to provide the index of each of the two vertices in the line. QUEST basically reads the initial list of points in as a zero-indexed array, which means the first entry is point number zero in the array.

In this case, line 1 is composed of points 1 and 2, so our first line is represented as "1 2"

Next we indicate the number of and list out all the polygon faces in the geometry. So if we have a rectangular box we have a total of 6 faces, as you can see in the diagram below.

The definition of a polygon is simply a list of the line indices composing that face preceded by the number of lines composing the face. The direction of the line makes a difference, here. The lines of a polygon must all go in the same direction - either clockwise around the face or counter-clockwise. So, if a line is defined backwards from the direction of the other lines in the polygon, you must place a minus sign before that line number, and QUEST will interpret that and represent the polygon properly.

The last section we'll discuss is text. I'm not entirely sure where the text section goes, but with the simple polygon block example, it seems we can just put the text section after the polygon face section.

To define the text, you must first provide the number of text objects to place on the geometry. Next, start listing out the text values. The first line of a text definition is the text string value. The next four lines after that represent the location/rotation transform for the text placement. To be honest, I'm not really sure how to interpret this. At some point I'll try to post some routines I built for reading and writing these rotation matrices, but in the mean time, to work with text, there is an easier way. Basically, just build your basic geometry, and manually place the text, save that out, and copy the transform matrix and use that.

So what we end up with with all this information should be a simple plain text file that we can feed into QUEST to build some simple rectangular box. Here it is:

I hope this has helped give some basic idea of how to build simple geometry files without using QUEST. Leave a comment if you have any questions about QUEST geometry that you'd like to discuss.

eVSM to QUEST demo video

2009-07-23T16:35:00.002-04:00

Here's a youtube video showing the eVSM to QUEST tool I've been developing at the Connecticut Center for Advanced Technology (CCAT).

If you're a QUEST user and have the eVSM software, and would like to try this functionality out, visit http://modsim.ccat.us/eVSM_Utilities and let us know you're interested. I'll be in contact when the time comes.

IIE Annual Conference 2009 - Applied Solutions presentation

2009-07-10T09:34:00.002-04:00

Here are the slides I presented this year at the IIE Annual Conference - Applied Solutions session. It shows some of the work I've been doing with bridging the eVSM Value Stream Mapping software with QUEST.

More to come later...

eVSM to QUEST Interface

2009-07-01T14:03:00.001-04:00

eVSM to QUEST Interface

Overview

The CCAT eVSM Utilities tool with the DELMIA QUEST (http://3ds.com) option allows you to export Value Stream Map information to the DELMIA QUEST (QUeuing Event Simulation Tool).

CCAT has developed a set of Simulation Control Logic (SCL) macros in QUEST for importing plain text files in tab-delimited format, and transforming that data into QUEST modeling constructs.

The CCAT eVSM Utilities makes it very easy to generate the plain text files and automates the subsequent import within QUEST.

Terminology

QUEST - QUeuing Event Simulation Tool. This is Discrete Event Simulation Software provided by Dassault Systemes, and is used for the modeling and simulation of stochastic manufacturing systems
eVSM - electronic Value Stream Mapping software (http://evsm.com).
NVU - Name-Value-Unit. An NVU is a construct within eVSM for holding process data. The Name portion describes the name of the data, the Value is simply the data value, and Unit is the name of the unit the Value is measured in

Format Overview

The overall format for importing to QUEST is as such:

Two rows of column header information
One row delineating units in columns
Process information in rows

Each row of simulation data represents a process in QUEST. Each column holds different data about the process.

There are three pieces of required data for each process in eVSM:

Cycle Time - The processing time of the process
Workstation - The name of the machine resource where the process is completed. This may also be a comma-delimited list of machines, each machine being capable of running the same process
Product - The name of the product part class of the process

Configuration Files

The eVSM->QUEST SCL macros were built to be flexible enough to import VSM data from eVSM using whatever standardized NVU names you want. An eVSM->QUEST configuration file has a .esm file extension, and is simply a list of setting names and values, similar to a QUEST .inc file.

The CCAT eVSM Utilities come with a pre-configured configuration file called QUEST_DIRECT.esm, and is stored in the DATA folder of the QUEST library you install the macros to. This file is used as the default configuration file for exporting directly from eVSM.

Aside from mapping NVU names to data fields the SCL builder macros need, there are also several high-level settings that can be used to control how the SCL builder macros run. The following are descriptions of several of these settings:

CELL_DELIM - The delimiting character between columns in the input text file. By default this is tab, but a comma can be used (and can be generated by MS Excel)
COMMENT_LINE - This character tells the SCL builder macros that a line is not to be read as a process. The default value is the # character
Geo - These settings allow you to specify the default geometry for buffers and machines
Workcell spacing options - These settings allow you to specify the spacing from a machine where the input and output buffers are to be placed. You may also offset the location of the machine labor point in the y-axis using the LABOR_Y_SPACING setting
Logic - These settings allow you to specify the logics to assign to various elements by default (in-buffer routing logic, process logic, etc...). The SCL file in which the logics are located must be compiled before the build. This can be done by listing your logic files in your configuration file with the variable name as SCL_FILE#, where # is a number between 1 and 5, and where no two listed logic files share the same number. These files will be compiled before the SCL builder macros execute

Data Overview

As previously mentioned, there are three required pieces of information you must provide for a process in eVSM. In reality, there are six pieces of data the SCL builder macros need in order to build a model; however, the following three pieces of data are automatically populated for you within eVSM :

Operation- The name of the process
Tag - A unique identifier for the process (no other process can have the same tag, but may have the same name)
Next Op - The Tag of the process downstream of the current process. This is used for identifying process sequences and routings

In addition to this required information, there is a set of optional NVUs you may provide to the SCL builder macros:

Changeover Time - The time required to change a machine from one process to another - modeled as a setup process in QUEST, between each process on the machine
Load Time - The time required to load a part onto a machine before the cycle process begins. This is modeled as a setup process and is executed when the same process is performed twice in a row. This means the load time must be included in changeover time, as the first load time is not run
Operator - The name of the laborer class to be required on a process. If a process has a changeover and/or load time assigned to it, the operator is assigned to the load/changeover process(es). Otherwise the operator is assigned to the cycle process
Operators - Depending on the assign_all_operators_to_process setting in the configuration file used. If the setting is 0, then the operators value represents the number of laborers in the labor class. If the setting is 1, then that number of operators is assigned to the process the laborer is assigned to
Num Elements - The number of elements in the machine class
MTTR/MTBF/Uptime - This is machine reliability data commonly used in simulation. Two of the three listed NVUs must be present to properly assign QUEST failures to the machines. If Uptime is provided, the NVU not present (MTTR or MTBF) is calculated based on the Uptime value and whatever value is present
Scrap - The rejection rate of the process. The rejection rate tells QUEST what percentage of parts to scrap, which means the parts are destroyed, and not repaired. The SCL builder macros do not currently support part repair
Geometry - The display geometry file name for the listed Workstation. This will override the configuration file level setting
TimeToNext - The time for the part to get to its next operation. The time delay is executed on the output buffer of the machine which the process is run on, and is not resource-constrained. The part enters the buffer, and after the TimeToNext is elapsed it moves on to the next process. This may be used for modeling outside operations which are not being modeled. This value may be provided as an SCL expression (meaning you may use build-in distribution functions)
Shifts - The number of shifts the listed Workstation of the process works.

Units

The builder assumes that the data file coming in was created using eVSM. As of eVSM version 4, units are placed in the third row, and so the builder assumes row 3 of the data file it reads contains the units for all the NVU's. The builder will look to these units to determine the units for: cycle time, setup time, load time, IAT, time to next operation, and Mean Time To Repair (MTTR). If no units are found for a specific variable, default values are assumed (minutes for cycle, setup, and load times; hours for IAT & MTTR)

Location/Layout Information

The SCL builder macros need to know where to put the machines listed in the Workstation NVU of a process. This can be provided multiple ways:

Shape of the Value Stream Map
Locations from an eVSM Spaghetti Chart
Manual location

When building from eVSM, you only have a choice between laying out machines in the shape of the VSM, or getting locations from an eVSM Spaghetti Chart.

If you choose the shape of the VSM, the SCL builder macros will place a machine in the location of the first process that uses that machine in its Workstation NVU. To locate based off an eVSM Spaghetti Chart, you must provide the name of the page the Spaghetti Chart is on, and the column from Excel corresponding to the place names set in the eVSM Spaghetti Chart. For example, if you name all your Spaghetti Places based on the values from your Workstation NVUs, you would tell the builder interface in eVSM to use the Workstation column for locating machines.

CCAT eVSM Utilities interface to SCL Builder Macros

Layout Options

Select a radio button to tell the builder how to locate machines in QUEST. Using "No layout" or "Layout file" will locate machines in the shape of the VSM. Using "Layout from page" requires that you specify the name of the eVSM Spaghetti Chart page, and the name of the column in the eVSM Excel Calculator spreadsheet which matches up processes with the location names in your eVSM Spaghetti Chart

esm File

You may specify an esm configuration file, if you have a customized file you need to use for the export. If left blank, the default QUEST_DIRECT.esm is used.

Pre- and Post-Build BCL Commands

You may specify a list of BCL commands to be executed before and after the SCL builder macros are executed. You may wish to compile logic files before the build, or to run different SCL macros after the builder execution.

These commands should be stored in the eVSM Excel Calculator spreadsheet. The worksheet the BCL commands are stored in should be named the same as the page your VSM is in, with "_BCL" appended on the end of the name. The easiest way to set this up is to click the "Import BCL from Excel" button, and the worksheet will be created, if necessary.

You must specify which columns contain which commands, where Pre-build BCL commands must have " *--PRE_BUILD_BCL*" in the first row cell of the pre-build commands column. " *--POST_BUILD_BCL*" must be in the first row cell of the post-build commands column.

Build Process

Once you have your settings complete in the CCAT eVSM Utilities, click the "Build" button. This will execute the eVSM Calculator, after which the CCAT eVSM Utilities will export the machine locations to Excel, as well as the Next Op data for each process (based on the connections between processes in your VSM). Finally, the CCAT eVSM Utilities will export your Excel data to a tab-delimited text file, and start QUEST and tell it to execute a BCL script generated with your pre- and post-build BCL commands, as well as commands to run the SCL builder macros.

The SCL builder macros begin by reading the spreadsheet data to an internal string array, and identifying all the column names, as well as reading units for different NVUs. Next, the builder copies data it has mapped to specific fields to a different string array, and begins the build process.

The build process begins with building part classes based on the Product column, then it builds a process for each row in the data array. Next, the process products and requirements are set based on the links between processes and their products. For instance, if two processes both have a process with tag "B10", the builder will interpret the process as an assembly process, and will require one of each of the Product part classes from the feeding processes. Then, based on the Product of the process, the process will be set to either pack one of the requirements into the other, or it will create a new part (if the product is not one of the requirements).

Next, shifts are added to machines based on the Shift data, if provided. If a machine is listed as having more than three shifts, then each shift is set as a time of 24 hours divided by the highest shift number found. If the maximum shift number is 3 or less, then each shift is set as 8 hours. Later on in the build, these shifts will be assigned to your machines. If the shift times need to be changed this can easily be done either manually or through BCL. The hardest part is done for you, which is creating and assigning the shifts to machines.

Next, workstations are created. A workstation is just a machine, an input buffer, and an output buffer. An input buffer receives and holds work until its machine can take it. An output buffer holds finished work until it can be moved to the next workstation.

As noted above, if TimeToNext is provided for a process, the workstation's output buffer will hold the part for whatever that TimeToNext value is.

Each workstation gets added to its own group so you may easily move a workstation around within a model.

Next, the builder will build connections between workstations. This is done based on the requirements of the processes on different machines.

Next, laborers are assigned to processes. If a process has loading or changeover associated with it then the laborer is assigned only to the loading/changeover process(es). Otherwise the laborer is assigned to the cycle process.

Next, loading and changeover machines are assigned to machines. After that, the builder assigns a process sequence to each part class, based on the chain of requirements and products of all the processes previously built. One noted problem with this is that the BCL statement to build a process sequence must contain the names of all the processes in the sequence, rather than simply adding one process to the sequence. This means that you may run against a string size limit when building a model with many long-named processes. To fix this, modify the BIG_STRING_SIZE constant in the build_from_vsm_generic.scl file to something larger.

The builder then assigns action logics, if applicable, as listed in the configuration file. Next comes machine failures, which are created and assigned if a process lists a machine's reliability as detailed above.

Lastly, the builder goes back to the original input array and finds any data columns that were not mapped to known constructs, and creates user attributes on the processes holding that data. This means you can very easily pass data between eVSM and QUEST without customizing the build_from_vsm_generic.scl file.

The builder then cleans up any build errors and data arrays, and saves the model to QUESTLib\Last_Build_Model.mdl. Also, the builder creates a BCL script of all BCL commands that get executed throughout the build process, and a log file is kept at QUESTlib\Output\writer_log.txt.

Automating DXF import to QUEST

2009-06-29T08:44:00.002-04:00

QUEST doesn't come with a BCL command for easily importing geometry, and although that would be very convenient, it's still possible to convert various CAD geometry to QUEST's PDB format.

QUEST doesn't have CAD converts baked into the QUEST.exe application file, but rather uses standalone executables located in the quest\bin folder in your QUEST installation. QUEST simply calls these executables using command line arguments to pass in information about what the user is trying to do through the QUEST UI. The converter then performs the conversion, and dumps out a temporary pdb file into your temp directory (default is C:\Tmp). QUEST has been waiting for the converter exe file to terminate, after which it just does a "retrieve" of the temp file the converter created.

So, in a nutshell, to automate this ourselves, we simply have to call the appropriate converter with the right command line arguments, and we can go around the relatively clunky QUEST UI for dealing with our CAD importing.

My use case will be generating dxf/dwg layouts from vector drawings in MS Visio, and generating a pdb file for QUEST. This means I'll be using VBA in Visio, but the same thing could easily be done using SCL (although there might be a few snags, such as making your SCL code wait until the conversion is complete)

Before I start into laying out the arguments for converting a dwg to pdb, I should mention that DELMIA/Deneb have made it a little easier on us in running these converters. They have provided some DOS batch files for setting environment variables, which the converters basically need to be sure you are a licensed QUEST user.

So to convert dwg to pdb, we use the dwg2pdb.bat and corresponding dwg2pdb.exe files. If you look at dwg2pdb.bat, you can see there's about 5 lines for telling Windows where dwg2pdb.exe is. You can get away with deleting all that junk, and finding the line that says:

%DENEB_BIN_DIR%\dwg2pdb.exe $1 ...

and replacing the %DENEB_BIN_DIR% with the full path to your QUEST installations bin dir (mine is C:\delmia\quest\bin)

The only environment variable you need to make sure is set is the LM_LICENSE_FILE, which you should have set already in your quest.bat file, and if your installation of QUEST works, you shouldn't even need to change this.

So, on to the command line arguments. To see what the arguments are, I quickly built an exe in VB6 that just echos out the command line arguments in a message box. So I renamed my dwg2pdb.exe to something else, and renamed my command line echo exe to dwg2pdb.exe. Then I went into QUEST and ran an import, at which time I was shown that there are four arguments you need to pass to run a dwg conversion:

The full path to the dwg/dxf input file
The full path to the output pdb file location
The full path to a configuration file called dwg_cmd (more on that later)
The full path to an output text callout file location

The first two arguments are fairly straightforward. You just need to get the full path to the input file, and decide where to send the output file.

The third argument is for the full path to a file called "dwg_cmd", which is automatically generated by the QUEST UI when you tell QUEST some of the parameters of the input geometry, such as the default length units, point tolerance, etc... On my system, at least, this file was stored in the quest directory. So I modified it to a default length unit of Inches, and copied the file to quest\bin. This will serve as my default dwg import profile.

The fourth and final argument was the full path to where you'd like the converter to build a plain text file containing all the text from the dwg/dxf file. You'll notice when imporing a file with text, you get the floating annotations containing your drawing text. I guess this is where that text comes from. The format is somewhat easy to understand. Basically, the first line details the number of text annotations there are. Then the annotations start. The first three lines of an annotation are the x, y, and z locations of the text callout, respectively. I'm not entirely certain what the next four lines are, though they could be rotation angles and font sizes. The next line is the number of characters in the callout, and the final line of a callout is the callout text.

Okay, so now we know all the arguments we'll need to pass to dwg2pdb.exe or .bat, to get things translated. When I tried this though, I got an error saying the executable could not find lmgr8b.dll, which is some runtime that QUEST needs in order to operate (and I'm assuming it's for the FlexLM license manager QUEST uses)

To fix this problem, I simply copied the lmgr8b.dll file from my quest dir into my quest\bin dir, and everything seemed to work. I could pass in my arguments and get a pdb file out.

So now anywhere I can generate command line arguments, I can also convert dwg/dxf files into the QUEST format automatically.

Selecting a file from a QUEST library (using SCL)

2009-05-20T13:20:00.005-04:00

QUEST SCL provides a means for an SCL programmer to call the standard file selection dialog box, where the user can pick a file from a specific folder from a specific set of libraries. This function is called FILE_POP_UP. You pass in a string or string array containing the directory (or directories) to be shown in the dialog box.

The way I use FILE_POP_UP, I use the inquire_config_path to populate a string array with all the libraries containing a specified folder name, and pass that array to FILE_POP_UP. I've encapsulated this functionality into a single SCL routine you can use:

routine get_filename( folder_name : String ) : String

Var

cpaths : array [50] of String

numpths : Integer

result : String

Begin

inquire_config_path( folder_name + '$LIB',cpaths, numpths)

FILE_POP_UP(cpaths, result)

return result

End

Now rather than havign to remember how to use inquire_config_path along with FILE_POP_UP, I can simply call a routine like so:

sel_file_path = get_filename( 'DATA' )

And of course, when you want the user to be able to select an SCL logic file, you'll want to be able to provide the option of selecting from the LOGICS and SCLMACROS folders from your libraries, so I've created a routine that takes two folder names, and combines their inquire_config_path results into a single array that gets passed to the FILE_POP_UP. Here it is:

routine get_filename_multiple( folder_name1 : String ; folder_name2 : String ) : String

Var

cpaths , cpaths2 : array [50] of String

the_paths : Array[ 100 ] of String

numpths , numpths2 , i , write_idx : Integer

result : String

Begin

inquire_config_path( folder_name1 + '$LIB',cpaths, numpths)

inquire_config_path( folder_name2 + '$LIB',cpaths2, numpths2)

write_idx = 0

for i = 0 to numpths - 1 do

if( cpaths[ i ] <> '' ) then

the_paths[ write_idx ] = cpaths[ write_idx ]

write_idx = write_idx + 1

endif

endfor

for i = 0 to numpths2 - 1 do

if( cpaths2[ i ] <> '' ) then

the_paths[ write_idx ] = cpaths2[ i ]

write_idx = write_idx + 1

endif

endfor

FILE_POP_UP(the_paths, result)

return result

End

You can use it like so:

sel_file_path = get_filename_multiple( 'LOGIC' , 'SCLMACRO' )

Executing shell calls in SCL and BCL

2009-05-20T13:17:00.008-04:00

The combination of QUEST BCL and SCL is extremely powerful not only for building and runnign simulation models, but also for providing a better experience for you to use QUEST models. BCL and SCL can allow you to greatly simplify modeling tasks, at the tradeoff of lowering QUEST's flexibility from infinite, to match with some set of assumptions you've come up with.

One powerful tool here, is the ability to generate system shell calls, and here I'll talk about this on Windows machines, only.

QUEST BCL has a call named "SYSTEM" which takes a single string argument, enclosed in single quotes. The QUEST BCL documentation gives an example of copying a file:

SYSTEM 'copy thisfile thatfile'

where thisfile is the path to the file to copy, and thatfile is the path to the file you want to copy to. This is useful enough, and pretty self explanatory, especially if you've used the Windows command line enough.

The example I'd like to provide lays in launching applications, and in this case, Microsoft Excel. To simply launch a file from the command line, all you need to do is feed the command shell the path to the file to open. Windows knows how to handle pretty much any file type you throw at it, and in the traditional GUI use of Windows you're prompted if Windows doesn't know what to do with the file.

This works fine for files where there's only one program for viewing or editing a particular file type. But what happens if you want to chose what program to use? Using the command line shell, we can specify the program file to use to open a file by passing the path of our file as an argument in starting the application. Most major applications support this.

So if you have Open Office set as the default editor of Excel files, passing an Excel file to the command shell will open it in Open Office. But if for some reason you want to open this file in Excel (without changing the default behavior) we just have to start Excel with our file as a command line argument.

So here's an SCL routine you can use to launch an Excel file:

routine launch_excel( file_name : String ) : Integer

Const

EXCEL_LOCATION 'C:/Program Files (x86)/Microsoft Office/Office12/excel.exe'

Var

bclerr : Integer

bclmsg : String

Begin

bclmsg = "SYSTEM '" + EXCEL_LOCATION + " "

bclmsg = bclmsg + file_name

bclmsg = bclmsg + " &'"

if( EXCEL_LOCATION <> '' ) then

bclerr = bcl(bclmsg)

endif

return bclerr

End

All we're doing is using the SYSTEM BCL call with the file_name argument as a commmand line argument. Pretty simple, eh?

Precompiled (always there) SCL routines

2009-05-20T13:08:00.006-04:00

Over the course of the last few years, I have developed some SCL utility logics that I use quite often and don't like having to copy over and over again. For example, a routine for replacing strings, or converting text to upper or lower case.

It's nice to have these logics, but normally, if you wanted to use them, you'd have to find a copy of the routines declared somewhere on your computer (possibly using my subroutine indexer). However, QUEST provides a directory within your QUESTlib folder called USERDEF, with a folder for logics that, if present there, will compile every time QUEST starts up.

This means that any procedures and routines within one of those USERDEF files will be available to you without having to copy them to the logic you're working on. They're always there. If you're trying to use a precompiled routine, however, you'll have to remember to declare the routine in the Extern section of your logic file.

What I usually do to cover this is to put in the extern definition for all my routines along with the definition of the routine in the USERDEF library. This way I can just go in and grab the extern def rather than the actual SCL definition.

In fact, to make it even easier to set up the extern definitions for all my routines, I've actually written an SCL macro that will do this, more or less, for me. You can download it at:

http://fournier.jonathan.googlepages.com/get_extern_names_from_scl.scl

Just load this into an SCL macro button, and when executed it will prompt you to select an SCL file. It will then search through the file you selected and export the extern representation for all your routines to a text file. It will then launch notepad and open this file for you.

Then all you have to do is copy the extern definitions. Hopefully that makes life a little easier for you.

Excel VBA UDFs for QUEST BCL (wow, enough acronyms?)

2009-05-06T09:02:00.007-04:00

If you have any familiarity with Excel VBA, you've probably made at least one User Defined Function (UDF) for use in an Excel spreadsheet. If you're not familiar with it, you basically just create a function within an Excel VBA standard module that may or may not take arguments, and returns something that can be displayed in Excel. For example, here is a simple function that just returns the sum of two arguments.

Function MySum(arg1 As Variant, arg2 As Variant)

MySum = arg1 + arg2

End Function

In this function, arg1 and arg2 are of Variant types, meaning the user is able to pass in a literal number or a selected Excel cell (called a Range). By defining variables as Variants, we can assume that whatever the user passes into the function can be cast into the variable type required by the operators we are using (in this case the addition/concatentation operator +).

What some people don't necessarily think of though, is to use VBA to create string concatenating UDFs. Here's an example that just puts two pieces of text together:

Function MyConcat(arg1 As Variant, arg2 As Variant)

MyConcat = CStr(arg1) & CStr(arg2)

End Function

You can see it's similar to MySum, except that we are using the & operator which is just for string concatenation in this use (where the + operator can be addition or concatenation). Also, we are making use of the built-in VBA function CStr to cast our variant data into strings. This is because the & operator requires strings as operands.

Now to the BCL part. We can use something similar to MyConcat to make it so we can easily create BCL commands by simply passing one or more arguments into specially created UDFs. Here's an example for creating a cycle process:

Public Function create_cycle_process(process_name As Variant) As String

create_cycle_process = "CREATE CYCLE PROCESS '" & process_name & "'"

End Function

So a user only has to pass in the name of the process they want to create, and VBA returns a properly formatted BCL command to execute in QUEST. This can be pretty handy.

Even better though, is that VBA allows optional arguments in UDFs, so we can easily account for the optional arguments in many BCL commands. A good example of this is the CREATE ELEMENT CLASS command, which requires that you provide the element class type and the element class name, but allows you to also specify the number of elements and the geometry file path to use for the class display. Without optional arguments you would have to write four different UDFs to be able to build a CREATE ELEMENT CLASS command with all the possible arguments. But with VBA we can do it one. Here's how:

Public Function create_element_class(class_name, elem_type, Optional num_elem, Optional geo_name)

Dim Result

Result = "CREATE " & elem_type & " CLASS '" & class_name & "'"

If Not IsMissing(num_elem) Then

Result = Result & " NUMBER OF ELEMENTS " & CStr(num_elem)

End If

If Not IsMissing(geo_name) Then

Result = Result & " GEO '" & geo_name & "'"

End If

create_element_class = Result

End Function

This function starts by creating the base BCL command using the required arguments, class_name and elem_type. Then, it uses the VBA function IsMissing to see if our optional arguments were omitted in the function call. If not, they are used to add to the BCL command. Finally, the BCL command is returned to the user. Now the user no longer needs to remember the proper syntax for creating an element class BCL command.

To make it even easier on the user, we can provide higher level functions that provide the proper elem_type for them, so they don't have to remember those either:

Function create_mach_class(class_name , Optional num_elem , Optional geo_name )

create_mach_class = create_element_class(class_name, "MACHINE", num_elem, geo_name)

End Function

Function create_source_class(class_name , Optional num_elem , Optional geo_name )

create_source_class = create_element_class(class_name, "SOURCE", num_elem, geo_name)

End Function

Function create_sink_class(class_name , Optional num_elem , Optional geo_name )

create_sink_class = create_element_class(class_name, "SINK", num_elem, geo_name)

End Function

Function create_buffer_class(class_name , Optional num_elem , Optional geo_name )

create_buffer_class = create_element_class(class_name, "BUFFER", num_elem, geo_name)

End Function

Function create_conveyor_class(class_name , Optional num_elem , Optional geo_name )

create_conveyor_class = create_element_class(class_name, "CONVEYOR", num_elem, geo_name)

End Function

Function create_accessory_class(class_name , Optional num_elem , Optional geo_name )

create_accessory_class = create_element_class(class_name, "ACCESSORY", num_elem, geo_name)

End Function

Function create_agv_controller_class(class_name , Optional num_elem , Optional geo_name )

create_agv_controller_class = create_element_class(class_name, "AGV_CONTROLLER", num_elem, geo_name)

End Function

Function create_labor_controller_class(class_name , Optional num_elem , Optional geo_name )

create_labor_controller_class = create_element_class(class_name, "LABOR_CONTROLLER", num_elem, geo_name)

End Function

Function create_carrier_class(class_name , Optional num_elem , Optional geo_name )

create_carrier_class = create_element_class(class_name, "CARRIER", num_elem, geo_name)

End Function

Function create_agv_class(class_name , Optional num_elem , Optional geo_name )

create_agv_class = create_element_class(class_name, "AGV", num_elem, geo_name)

End Function

Function create_labor_class(class_name , Optional num_elem , Optional geo_name )

create_labor_class = create_element_class(class_name, "LABOR", num_elem, geo_name)

End Function

Function create_path_system_class(class_name , Optional num_elem , Optional geo_name )

create_path_system_class = create_element_class(class_name, "PATH SYSTEM", num_elem, geo_name)

End Function

Hopefully this has given you a good primer on using VBA UDFs to create QUEST BCL commands in Excel, so you can smarter BCL scripts that will be easier to modify and to execute in QUEST.

Wait Until Event

2009-03-13T09:02:00.001-04:00

A lot of times in modeling a system in QUEST there comes a need for some synchronization between different elements. For instance, one model I made had a large piece removed from the main assembly part, which was stored until the main assembly part arrived at a specified machine. Once that assembly part leaves for the machine, the large part should start being delivered to the machine (while the machine is running a process to prepare the assembly part for installation of the big part).

When I first started with QUEST, I probably would have written some logic on the storage buffer holding my part to look at the machine at a specified time interval to see if the main assembly part had arrived yet. You can set the time interval to whatever you want, and there are drawbacks no matter what. If you specify a small interval (like 5 seconds), your model will slow down to a crawl because your logic is running more or less constantly. Add multiple elements running this logic and you can kiss model performance goodbye.

So what if you specify a larger interval? Again, you're still going to be running your logic a lot more than you need to, and with the larger interval you run the risk of not noticing the main assembly part arriving until too late.

There are a few ways we can address this problem without using a time interval to constantly keep checking our machine. Some would suggest using signals, where our machine would send a signal to our buffer saying the part is there, and it's time to route the part on to the machine. This will have good performance in the model, as the logic in the buffer just uses a WAIT UNTIL SIGNAL SCL command to wait.

What I don't like about this is the need to write logic for the machine to use to send the signal to the buffer. And what if we can't be sure what buffer is holding our part? Then our logic has to search for the part and alert that buffer using a signal. This is all doable, but I prefer to use (what I think is) a simpler approach: the WAIT UNTIL EVENT SCL command.

The WAIT UNTIL EVENT command would be used similar to how we would use the WAIT UNTIL SIGNAL command, except that QUEST is raising the event for us, so no logic needed anywhere except on the buffer routing the part.

To use the WAIT UNTIL EVENT command, you simply provide an event constant, and optionally a pointer to the element/element class you want to watch, as well as whether you want your logic to run right before the event, or right after. There are some other options (you can look for events on a part/part class, or segment).

So for the example above with the assembly part and the part that needs to move to the machine, our buffer would just have a loop that goes something like this:

while( true ) do

WAIT UNTIL EVENT PART_XFER FOR ELEMENT_CLASS the_elem_handle

-- look at the_elem_handle's inparts to see if our assembly part is there...

endwhile

and then our logic can continue, and route the part out of the buffer to the waiting machine. One thing to note here, too, is that to use the PART_XFER constant you must have #include at the top of your SCL file or your logics won't know what PART_XFER is and it won't compile. You could just look up the numeric codes for the event constants if you'd prefer, but the code is easier to read (especially after a year without looking at or thinking about that particular logic) and more future proof if you use the constant names.

This is just one example where we can use the WAIT UNTIL EVENT SCL command in place of using signals. Your mileage may vary, in that the events we want may not be exposed for use in the WAIT UNTIL EVENT command (for instance, when a part actually arrives at an element). In these cases you may need to use signals, but hopefully you'll be able to use WAIT UNTIL EVENT just as effectively.

How to run BCL from Excel (the simple way) Part 2

2009-03-02T16:23:00.003-05:00

In the previous post, I showed you how to set up a batch file that launches QUEST with the path to a BCL file passed as the command line parameter. This post will bring us the rest of the way to being able to save out a series of BCL commands generated in Excel out to a BCL file.

The easiest way to create the Excel portion of this setup is using a VBA-based Excel Addin (.xla file). The XLA, once activated by the user, is available whenever Excel is running, and we can build toolbar buttons to execute the macros we're using.

The macros themselves are pretty straightforward if you're accustomed to writing VBA in Excel. The VBA Project is unlocked and unprotected, so you can go in and start editing/hacking away as you'd like to.

Download the XLA file here. Understand that it's intended just for demonstration purposes and comes with no warranty.

To install the Addin, save the XLA file to your computer and note its location. Then start Excel and go to Tools->Add-Ins. Select the "Browse" button and navigate to the XLA file, wherever you saved it, and that's it. The Addin will open and you'll see a new toolbar (named BCL_Launcher_Toolbar) with a pair of buttons on it.

To use the buttons, first select the cells containing the commands you want to save/execute. The button on the left will just save the commands to a text file, while the button on the right saves the commands and then launches QUEST and executes those commands.

The first time you use the Addin, you'll be prompted for the location of the BCL file where you want your commands saved to, as well as the location of your QUEST BCL BAT file that you created in the previous post. After that you should be good to go.

Download Addin

How to run BCL from Excel (the simple way) Part 1

2009-03-02T15:34:00.000-05:00

For some time now I've been building QUEST models by using BCL script rather than the traditional User Interface. I do this because it provides me with a very detailed (and procedural) look at what I've done to a model, and helps to glean out what assumptions I've made along the way.

It also lets me rebuild a model from scratch whenever I want, so I can (somewhat) easily modify some model parameter and have that change made in my model. To make changing parameters easier I build my BCL scripts in Excel using formulas. When I need to rebuild my model I can just click a user button in Excel and up pops QUEST to execute my script.

The following posts will tell you how to set up the same thing in your version of Excel.

Since we're basically just going to build a text (.bcl) file in Excel and execute it in QUEST, we need to first set up a QUEST .bat file that will open QUEST and execute the commands in a BCL file. Looking at the online documentation, all we have to do is append "-b" on to the call to QUEST.exe with the BCL file name.

To set up a quest_bcl.bat file just make a copy of your quest.bat file (or whatever .bat file you use to initialize environment variables before starting QUEST, usually Deneb\Quest\Quest.bat) and find the line where QUEST is being started (I believe it's something like "start/max %DENEB_PRODUCT%.exe %1 %2..."), and replace it with this:

quest -b < %1

The "< %1" just tells the command line to take the first command line argument passed in and pass it on to "quest -b".

To test this, try creating a simple BCL file that creates a machine and places it at some location, then transfers control of the program to the user (otherwise QUEST will just close out having completed its task):

CREATE MACHINE CLASS 'Machine1'

LOCATE ELEMENT 'Machine1_1' AT 100, 100, 100

TRANSFER TO MENU

Save this into a plain text file and name it what you'd like (preferably with a .bcl extension, but it doesn't matter much). Note the full path to the file.

Next, open a command prompt and navigate it to the directory where you saved your quest_bcl.bat file. In the command prompt type:

quest_bcl.bat "bcl_file_path.bcl"

where bcl_file_path is the full path to the BCL file you saved (unless it's in the same directory as your quest_bcl.bat). You don't have to enclose the BCL file path in double quotes unless there is a space in the path.

If everything is working right, QUEST should launch and create a machine at the specified coordinates.

In the next post, I'll show you how to set up a simple Excel Addin (.xla file) that will let you build a BCL file from a set of Excel cells and launch it in QUEST.

Select a part class

2009-02-20T13:36:00.002-05:00

Since I've already posted how to select an element and a process using SCL, and because there was recently a question regarding this in the QUEST Google Group, I figured I'd post code for selecting a part class.

All this code does is populate an array wtih the names of all the part classes in the current model, then passes that to a list_pop_up, which returns the index in the array of the selected item. The list_pop_up routine returns a boolean integer telling whether or not something was actually selected (eg the user didn't hit cancel). So if this return value is true then just return the part class referenced in the array...

routine select_a_pclass() : Part_Class

Const

max_pclass 250

Var

result , the_pclass : Part_Class

num_pclasses_found , pick_process , list_picked : Integer

the_pclasses : Array[ max_pclass ] of String

Begin

num_pclasses_found = 0

the_pclass = first_pclass

while( the_pclass <> NULL ) do

the_pclasses[ num_pclasses_found ] = the_pclass->name

num_pclasses_found = num_pclasses_found + 1

the_pclass = the_pclass->next_pclass

endwhile

--do a list popup using the_pclasses

list_picked = list_pop_up( 'Select a part class' , the_pclasses , pick_process , true )

if( list_picked ) then

return get_part_class( the_pclasses[ pick_process ] )

endif

End

How Filehamster Saved My Life

2009-01-16T15:00:00.005-05:00

I don't know about you, but in the course of developing SCL macros and logics I sometimes tend to make bad choices, and undoing those changes can be pretty painful, especially if I went and modified something on a large scale (i.e. adding a call stack on 328 subroutines in an SCL file and finding out that my implementation gets extremely slow as the stack grows).

Thankfully, for the past couple years I've used a tool called FileHamster from MOGWare, which is a free and extremely easy to use backup program that basically sits and watches any files you want it to, and when you change it it snags a copy and stores it for you. You can add comments to a revision as it's copied or later on (like "Last backup before adding call stack") so you can easily identify the point where you made a change you need to reverse, and restore your file to that version.

Filehamster just takes a copy of what's changed and saves it out for you to a backup directory. But there's very little overhead in setting up a file watch, and with SCL files we're dealing with text files in the size range of 1-300K, so it would take a while to use up an appreciable amount of hard disk space. If you're that concerned there's a plugin for sale that'll compress each revision for you.

There's actually a set of plugins for sale on their site for extending FileHamster into something more like a full-on source control package, but I'm going to hold out until they come up with a plugin that can hear that voice in the back of my head asking "does he really think this is going to work?"

SCL Call Stack

2009-01-13T16:02:00.004-05:00

If you saw my last post on compiling SCL files from SCL, you may have seen that there are some array utility routines I've written that allow you to insert and remove array elements through a simple call providing the array and the number of elements in it.

After creating these routines, I thought they'd be perfect for implementing a call stack in SCL. Having a call stack available in SCL would mean we can more easily track down the source of bugs in our scl subroutines, especially if they're more generic utilities that may be called from any number of different routines.

So the way I'll be using this is in a very large (8,000+ line) SCL utility where many routines are simply wrappers around BCL commands that make it so I don't have to write out BCL statements again and again. Basically any time a subroutine starts or ends I just write the stack out to a text file; and if the macro crashes, I just check the latest stack text file and see what subroutines were in the stack, so I can track the problem down.

call_stack.scl

I'd suggest you save the call_stack.scl file into QUESTlib/UserDef/Logics so it's always compiled and ready to go when you need it...

Basically there are three procedures in the call_stack.scl file you need to worry about: start_procedure, end_procedure, and print_stack. Just call start_procedure and end_procedure with the name of your subroutine as an argument, and the stack will reflect all subroutines you've got running.

However, like I said earlier, I have 8000 lines of SCL code with over 300 subroutines. So how am I supposed to put in a call to start_procedure and end_procedure for all those subroutines?

The answer is using SCL, what else? So I went and wrote an SCL macro that lets me select an SCL file, and it then goes through and identifies each subroutine in the file, and adds a call to start_procedure at the beginning and end_procedure at the end of each subroutine, with the name of the sub as the argument. The file gets saved out as the original filename with "_cs" appended on, so you can go and copy it over if you want, or just run that for debugging purposes.

add_call_stack_to_scl_file.scl

Model Scaling

2009-01-05T16:33:00.005-05:00

I recently built a QUEST model on a CAD layout and it turned out the layout wasn't properly scaled. This is easy enough to fix, just a matter of either modifying the CAD part in the QUEST drawing world, or just scaling it in the dimensions section of the layout accessory.

But what about the elements? I had to scale the layout to about 120% of its original size and didn't feel like moving all the machines and buffers and everything to their new locations on the layout.

So what would I do other than write an SCL macro that lets me move all elements in a model relative to some new scale. Here's the code.

Basically what it does is populates a spot structure, multiplies the location coordinates by the scale input by the user, and locates the element on the spot's new coordinates.

The best part about writing this macro was that it took about 5 minutes, just by copying in SCL subroutines I've previously written and was able to find using my SCL Subroutine Indexer.

Update: When using this macro I found it might be better to be able to scale the model differently along various axes. So I went and modified the macro to scale each axis to different values as input by the user using a var_pop_up.

Compiling SCL from SCL (ish)

2008-12-18T15:14:00.007-05:00

I don't know about you, but in the past I've developed QUEST solutions where it would have been nice to be able to use SCL code to identify a set of other SCL files to compile. However, there is no straightforward way to do this as using the SCL_COMPILE BCL command from an SCL script will generate an error and not compile the SCL file.

There is a workaround, however, and that is to use BCL to execute an SCL subroutine which returns the path of an SCL file to the bcl_msg BCL variable. You can then use the SCL_COMPILE command passing bcl_msg as an argument to compile an SCL file selected using SCL code.

The downside is that if the routine doesn't return a file path the BCL code still tries to compile the blank string file path, and shows an error in the message window. Unfortunately (as far as I can tell) you can't use conditional statements in a BCL script, so there's not much we can do about this. I'd say if you need to be able to compile SCL from SCL, it's worth the small inconvenience of seeing the error message when you don't specify a file.

I've used this technique to compile SCL files listed in a configuration file (not the QUEST kind) that could only be parsed using SCL (rather than straight BCL), so that users can specify different SCL logics in building a QUEST model from an eVSM file.

This may not be of any use to anyone reading this, so I've provided an example which hopefully will make using QUEST just a little bit easier to use. I don't know about you, but I often debug my SCL code by writing a little, then compiling it in QUEST, until it's all done and working. However, if you're working on multiple SCL files it can be a pain to go to the Run->Simulate->Compile button and pick files in various folders.

So what I've done is created a BCL macro that calls an SCL routine that keeps track of (up to) the last 49 or so SCL files that I've compiled (in the current session) and gives me the option of selecting another file to compile. So I've basically duplicated the Run->Simulate->Compile functionality, and added a list of the most recently compiled files for you to chose from.

You can get the BCL script here and the corresponding SCL file here. Keep in mind that you need to modify the BCL script to compile the SCL file wherever it is saved on your computer.

Select an Element

2008-11-11T11:01:00.004-05:00

QUEST SCL provides a function for selecting items (including elements) from the QUEST world, aptly named Select. Basically, you tell the function what you want to pick (elements, cad_parts, etc...), the selection mode (mouse pick, pick from a list, or key in the name), and you pass in a string variable that will be set by the routine to the selected item's name (You also have to specify a text prompt, and whether or not you want the selected item to be highlighted).

I usually don't need to use all the available options in the Select function, so I've put together a routine I use often that I can drop into an SCL macro or call with an Extern reference, so here it is:

routine select_an_element( prompt : String ) : Element

Var

elem_name : String

picked_elem : Element

Begin

while( select( prompt , ELEMENT , PICK_MODE , TRUE , elem_name ) ) do

picked_elem = get_element( elem_name )

endwhile

return picked_elem

End

Like I said, this is just an easy to implement routine you can drop into your code without worrying too much about it, which is how I like to program...

Set part class dimensions

2008-10-21T14:34:00.003-04:00

As far as the QUEST online documentation shows, there is no BCL command for setting a part class' dimensions.

I thought it would be possible to do this by exporting a part class to a text file, modifying the text file with the new dimensions, and then re-importing the text file to overwrite our part class with the new dimensions.

Here is the resulting SCL macro.

You can use it from within SCL by calling set_pclass_dimensions with a handle to the part class, then the 3 arguments to set the part class dimensions to.

You can call it from a BCL script using the following commands, setting the full path to the set_pclass_dimensions.scl file, substituting Part1 with the name of the part class you want, and setting the dimensions to the sizes you want:

SCL_COMPILE 'set_pclass_dimensions.scl' 0

SCL_EXEC set_pclass_dimensions_by_name WITH ARGUMENTS 'Part1' , 100 , 200 , 300

SCL Subroutine Indexer

2008-10-21T13:15:00.006-04:00

If you're anything like me, you've written a large variety of SCL logics and have tons of procedures and routines buried in files which are in turn buried in different QUEST LOGICS and SCLMACROS libraries. Sometimes I need a logic that I know I've already written, but can't remember where it is. I use Google Desktop to find files, but it is unable to search within the text of a plain text file unless it has an extension it recognizes (i.e. not .scl).

Rather than write a plugin for Google Desktop to enable SCL search, I went the quicker, dirtier, and easier path (for me, anyway) and wrote a couple macros in Excel to index a set of SCL files (extracting all procedure and routine declarations) into an Excel worksheet. A while back I wrote an interface for Excel's AutoFilter that makes setting filters on large datasets a little easier than without.

One thing to note is I haven't set it up to read any subroutine declarations that span multiple lines (using the line continuation character "\") so at the moment it won't pick up the full declaration.

Updated: 10/21/08 - Modified the auto-filter helper to run faster in populating the result list box for large data sets

Click here to download the SCL Indexer

To use this indexer, simply copy the SCL_Indexer.xls file to your computer, and open it in Excel. I signed the VBA project with a digital certificate created on my own computer, so you should be able to import the certificate, but to be honest I'm not sure how that will work, and you may be stuck hitting "enable macros" every time you open the file. If nothing else, you can try saving the file to a trusted location.

When you open the file (with macros enabled) the indexer will create a toolbar called "AutoFilterHelper". This toolbar contains the buttons for running the indexer and searching the index (In Excel 2007 a section will be added to the Addins ribbon with the buttons).

To use the indexer just click on the binocular button. This will open a form that allows you to select a directory or file, and to index it. You may select to index any subdirectories from a directory. Hit cancel while it's indexing if you want it to stop.

Once the index is built you will see that the worksheet is populated with all procedure and routines indexed, with the return type (Null means it's a procedure) and arguments listed. The file name for each subroutine is listed as well.

To use the auto filter helper, click on the magnifying glass, and select the column header you want to search. It may take some time to populate the result box, but you will see a list of all subroutine names in the bottom right box. To search the list, start typing in the text box and the results in the result box will reflect what you've typed in the search box.

Select an item in the result box and click "Apply Filter" and that filter will be applied in the index worksheet. For more information on auto filter: http://www.contextures.com/xlautofilter01.html

SCL Code "Profiler"

2008-10-06T11:57:00.003-04:00

I've written a fairly large SCL macro, which you'll be able to get soon here.

In order to keep tabs on how much of this 8000+ line macro is real code, I decided to write an SCL logic "profiler", which really just goes through and counts the number of comment lines, blank lines, and everything else, and reports it out for you. So really in my (currently) 8195 lines of code there's really 5978 lines of code, 1061 blank lines, and 1156 lines commented out.

The line counter code can be downloaded here.

String Replace

2008-10-01T13:09:00.002-04:00

This routine gives you similar functionality to the replace function in VBA. Basically, the routine just reads through a string argument and replaces any instance of to_replace with replace_with.

As far as I can tell there is no built-in function in SCL for doing this...

routine replace_string( full_string : String ; to_replace : String ; replace_with : String ) : String

Var

result : String

start_idx : Integer

rep_idx : Integer

Begin

start_idx = 11

result = full_string

while( index( result , to_replace , start_idx ) > 0 ) do

rep_idx = index( result , to_replace , start_idx )

result = leftstr( result , index( result , to_replace , start_idx ) - 1 ) + replace_with + rightstr( result , len( result ) - index( result , to_replace , start_idx ) - len( to_replace ) + 1 )

start_idx = rep_idx + len( replace_with )

endwhile

return result

End

Batch Control Language (BCL)

2008-09-19T14:24:00.022-04:00

QUST has two macro/scripting languages, SCL and BCL. BCL is short for Batch Control Language, and it is basically there to let you automate almost everything you can do through the QUEST User Interface. This automation can be done through straight-up BCL scripts, which are plain-text files containing a series of BCL formatted commands. An example of such a command is:

CREATE SOURCE CLASS 'Source1'

which will create a new source class named Source1. This will also create one element in the Source1 class. You can locate this element using the follwing command:

LOCATE ELEMENT 'Source1_1' AT 100 , 100 , 0

This kind of scripting can be tedious and error-prone. The good thing is, almost all BCL commands are supported for use through SCL programming. This means you can write an SCL script to read a list of element names and locations, and execute BCL calls to create and locate those elements.

To use BCL within an SCL script, you use the BCL( command_text : String ) : Integer function. All you do is provide a string argument that contains your BCL command, and SCL will have QUEST execute it. The BCL function returns an integer containing the error code, so you can know whether or not the command executed properly. A list of error code numbers and their corresponding descriptions can be found in the bclerr.inc file in your QUESTlib\Include folder.

It's also possible to have QUEST execute a BCL script as soon as the QUEST.exe program starts. Details for setting up QUEST to run this way from Excel can be found here.

So, assuming you've set up QUEST to run a BCL script generated in Excel, you may now be wondering how to generate BCL scripts in Excel. I have set up a number of Excel VBA User Defined Functions (UDFs) that can be used to generate a subset of all the BCL commands. I'm currently working on building a version of this that I can release for everyone to use, but until then why not start building your own BCL UDFs?

upper & lower case

2008-09-19T14:24:00.019-04:00

Sometimes in writing QUEST logics, especially those that deal with user input or reading from text files, I've had to compare two pieces of text for equality where the case of the text wasn't an issue. The thing with SCL is that text comparisons are case sensitive, which meant I needed a way to convert a text string to either all caps or all lower case characters. I never found anything for this in QUEST's SCL docs, so I made my own, and here they are. The routines work by reading each character in a string individually, and seeing if it's already in the desired case. If not, we just add or subtract 32 to/from its ASCII value to convert between upper and lower case characters in ASCII text.

Here's a download if you don't want to copy the text

routine is_lower( the_string : String ) : Integer

Const

first_lower 97

last_lower 122

upper_to_lower 32

Var

the_char : String

result : Integer

Begin

the_char = leftstr( the_string , 1 )

if( asc( the_char ) <= last_lower AND asc( the_char ) >= first_lower ) then

result = true

else

result = false

endif

return result

End

routine is_upper( the_string : String ) : Integer

Const

first_upper 65

last_upper 90

upper_to_lower 32

Var

the_char : String

result : Integer

Begin

the_char = leftstr( the_string , 1 )

if( asc( the_char ) <= last_upper AND asc( the_char ) >= first_upper ) then

result = true

else

result = false

endif

return result

End

routine upper( the_string : String ) : String

--Return upper case version of the_string

Const

first_lower 97

last_lower 122

upper_to_lower 32

Var

i : Integer

result , check_char : String

Begin

result = ''

for i = 1 to len( the_string ) do

check_char = substr( the_string , i , 1 )

if( is_lower( check_char ) ) then

check_char = chr( asc( check_char ) - 32 )

endif

result = result + check_char

endfor

return result

End

routine lower( the_string : String ) : String

--Return upper case version of the_string

Const

first_lower 97

last_lower 122

upper_to_lower 32

Var

i : Integer

result , check_char : String

Begin

result = ''

for i = 1 to len( the_string ) do

check_char = substr( the_string , i , 1 )

if( is_upper( check_char ) ) then

check_char = chr( asc( check_char ) + 32 )

endif

result = result + check_char

endfor

return result

End

Inquire Element Location

2008-09-19T14:24:00.015-04:00

The QUEST BCL Language has a command called "Inquire Element Location", which just takes the specified element's location and prints it to the BCL output window. It may not seem at first to be of much use there, but we can make use of a special variable declaration in SCL to access this output text.

To illustrate using the BCL output from SCL here's an example SCL macro which will print the location of every element in the current model to a tab-delimited text file, and launch that file for viewing in Excel. I have another macro which I may share that will let you read this format back into QUEST, modifying element locations as read from the text file.

Handling 6 Degree of Freedom data in SCL

QUEST elements are located in 3D space in the QUEST world, and can be rotated about 3 axes, giving a total of six pieces of information required to completely locate some element in 3D space in QUEST. In order to give our SCL code some degree of modularity and elegance, we need an easy way of passing all the location information.

We can settle for just passing all six parameters around every time we want to work with QUEST locations. Over time this can get old, especially if you work a lot with locating elements in QUEST. Also it helps to have a good methodology in place for dealing with locations, like having a routine for pulling the location of an element, or a procedure for locating an element with little hassle.

The solution I use is to have an SCL Structure for a 3D location. From the QUEST SCL docs:

A structure is a group of variables which can be manipulated collectively or individually. A structure is analogous to a record which consists of many fields.

What this means to me is that I can have as much information stored in a structure as I need, and move that information around by passing just a single variable.

The name I chose for my 3D location structure was "spot", and here's how I've defined a spot in SCL:

structure spot

x : Real

y : Real

z : Real

yaw : Real

pitch : Real

roll : Real

elem_there : Element

endstructure

Basically the spot is just keeping track of 3D location and orientation, storing these values as type real. I also have a handle to an element, which you would set when inquiring about en element's location. My thinking there was that some day I might need a way to populate locations in a QUEST model without overlapping items, so I added the elem_there field.

One thing to note about using structures, is that you can work with a structure variable, or a pointer to a structure variable. Those of you with experience in C probably know the distinctions and caveats to each technique, but I usually use a pointer to a structure, just because it's a little less confusing thinking about whether or not the structure I'm using is what I think it is.

Moving forward, we now need a way to inquire the location of an element in QUEST and return a pointer to a spot structure, after populating a spot. The routine itself makes use of a bcl command called "INQUIRE ELEMENT LOCATION", which simply places the location of the element in a comma-delimited text string on the BCL command output window.

Accessing the text in the BCL command output window is pretty simple, just declare a variable at the top of your scl file in a declaration section called "BCL_VAR". The string to declare for the BCL command output window is "bcl_msg : String". The only other BCL_VAR is "bcl_status : Real" which will tell you the result of a BCL command. More on that another time.

So your BCL_VAR declaration should look like this:

BCL_VAR

bcl_msg : String

Now for the inquire_loaction routine:

routine inquire_location( the_element : Element ) : @spot

Const

the_delim ','

Var

bcl_err : Integer

the_loc : String

result : @spot

Begin

result = new()

if( the_element <> NULL ) then

bcl_err = BCL( "INQUIRE ELEMENT '" + the_element->name + "' LOCATION" )

the_loc = bcl_msg

parse_str( the_loc , the_delim , result->x , result->y , result->z , result->yaw , result->pitch , result->roll )

endif

return result

End

A few things to note:

result is declared as being of type @spot, which is a pointer to a spot structure
We make use of the new() routine to allocate memory for a spot structure. We have to remember to free this portion of memory later using the free() procedure.
We make use of the parse_str routine for parsing the string into chunks for us. This is a built in routine in SCL.
We use the -> symbol as a member pointer rather than a dot because we're working with a pointer to a structure. If we were using a straight structure, we'd us a dot.

The routine basically just executes the "INQUIRE ELEMENT LOCATION" BCL command, extracts the output text from the BCL output window, and parses it to a new pointer to a spot structure, and returns the pointer to the calling function.

To tie it all together, see the write_elem_locs.scl file to see how we can build a tab-delimited text file of all our element names and locations, and launch the file in Excel.

You can execute the macro by saving it to an SCLMACROS folder in a QUEST library, or you can compile the file and execute the write_all_locations function through BCL.

Select A Process

2008-06-05T20:38:00.007-04:00

QUEST has a pretty powerful construct that I haven't really seen in any other simulation packages: processes. A process is a data structure in QUEST that holds pretty much all the information you need to run a process in a simulation.

SCL exposes a lot of the information in a process, which you can see in the SCL documentation. However, selecting a process interactively in SCL is not built in (as far as I can tell). So here's a routine for selecting a process in a QUEST model.

routine select_a_process() : Process
Const
max_process 200
Var
result , the_process : Process
num_processes_found , pick_process , list_picked : Integer
the_processes : Array[ max_process ] of String
Begin

num_processes_found = 0
the_process = first_process
while( the_process <> NULL and num_processes_found < max_process ) do
the_processes[ num_processes_found ] = the_process->name
num_processes_found = num_processes_found + 1
the_process = the_process->next
endwhile
list_picked = item_pop_up( 'Select a process' , the_processes , pick_process )
return get_process( the_processes[ pick_process ] )
End

Basically the macro traverses the QUEST model's linked list of processes and adds them to an array. Then we use the item_pop_up routine to select a process from a list generated by our array. The item_pop_up returns the index of the selected process in the array, and we return that process pointer. You can use this routine to select a process that you want to act on in a SCL macro.

File I/O

2008-06-04T18:14:00.045-04:00

QUEST SCL has a set of easy to use subroutines for dealing with file input and output. If you've done file I/O in VB or VBA you'll see the syntax is very similar.

File I/O is performed in SCL using file streams. This basically means that you use SCL to open a file and either read it or write to it. To open a file you first need to determine the file stream you want to use. This is just an integer value unique to the file you want to access. If you're planning to open a file stream and close it within a single subroutine the file stream should be an integer between 1 and 15. Anything above that is a global stream, which can be manipulated from any subroutine you're running. This complicates things a bit, and I personally don't use global streams very often. This is because you can pretty easily just append data to a file if you prefer.

There are two ways to pick a stream. You can use a literal integer value and just keep an eye on which you use (in case you decide to manipulate several files at once). Or you can do what I do and use an integer variable so it's easy to change things around, and it makes the code easier to read.

There is a way to ensure you always have a good file stream to use, which is to check file streams starting with one until you find one that's not opened yet. This is facilitated with a while loop and the QUEST built in function is_open.

The is_open function just takes in an integer value and returns true if it's in use as a file stream and false if it's not. Here's the start of a procedure for writing data to a file:

procedure print_data_to_file()
Var
out_stream : Integer
Begin
out_stream = 1
while( is_open( out_stream ) ) do
out_stream = out_stream + 1
endwhile
End

When this procedure gets to the end, out_stream will have a value that is acceptable for use in manipulating file operations. But how do we start file manipulation? With the "open" procedure. This procedure is a little different in that arguments are not passed in parenthesis, but instead the command is built like a sentence. The syntax is:

OPEN FILE name FOR [ BINARY | TEXT ] { OUTPUT | APPEND | INPUT } AS unit_no

In this procedure we can leave out the binary/text declaration, as SCL will default to text. We need to declare how we're opening the file, though. We have the option of: output, append, or input. If we output, then if the file exists it will be wiped clean and started new. If we choose append we have to make sure the file exists to begin with or we'll get an error. If we do append, then any data we write to the file just gets appended to the end of the file. Lastly, if we open for input then we can't make any changes to the file; we're just reading its contents.

From this point on things are pretty straightforward if you're writing out to the file. You simply use the "write" procedure and specify the output stream in order to output to that stream. Here's an example procedure:

procedure print_machine_class_names()
Var
   out_stream : Integer
   check_class : Element_Class
Begin
   out_stream = 1
   while( is_open( out_stream ) ) do
   out_stream = out_stream + 1
   endwhile
   OPEN FILE 'C:/Tmp/machine_names.txt' FOR OUTPUT AS out_stream
   check_eclass = first_element_class
   while( check_eclass <> NULL ) do
   if( check_eclass->type == MACHINE ) then
   write( #out_stream , check_eclass->name , cr )
   endif
   check_eclass = check_eclass->next_eclass
   endwhile
   close #out_stream
End

This is a very straightforward example that first creates/resets the machine_names.txt file, and then proceeds to print out the name of every machine encountered in the model. The last thing it does is close the file stream using the close procedure.

Reading data from a text file is a little less straightforward but not much harder to do. We need to start the same way as writing: find a valid file stream and open the file. Here's the base code:

procedure read_data_from_file()
Var
   in_stream : Integer
Begin
   in_stream = 1
   while( is_open( in_stream ) ) do
   in_stream = in_stream + 1
   endwhile
   OPEN FILE 'C:\Tmp\file_read_example.txt' FOR INPUT AS in_stream
End

Once the file is open, we need to start reading the file. We can do this using the read_line procedure. The syntax is as follows:

READ_LINE ( [ #unit_no,] lvalue )

where lvalue is a string variable we pass in whose value gets assigned as the next line read from the specified file stream. One thing to note here, is that when SCL gets to the end of the file, read_line will return a special predefined string called $EOF. We just keep reading until read_line gives us the $EOF string.

Here is some sample code for reading lines from a file and writing them to the screen.

procedure read_data_from_file()
Var
   in_stream : Integer
   curr_line : String
Begin
   in_stream = 1
   while( is_open( in_stream ) ) do
   in_stream = in_stream + 1
   endwhile
   OPEN FILE 'C:\Tmp\file_read_example.txt' FOR INPUT AS in_stream
   read_line( #in_stream , curr_line )
   while( not curr_line == $EOF ) do
   write( curr_line , cr )
   read_line( #in_stream , curr_line )
   endwhile
   close #in_stream
End

File I/O is a powerful tool for use in QUEST. You can use this to read in a tab-delimited data file with any number of possible uses. For example you can read in process cycle times and assign those times to the specified processes. The possibilities here are really endless, and hopefully this will give you a good idea of how to get started.

Simulation Control Language (SCL)

2008-06-03T22:15:00.000-04:00

Simulation Control Lanugage (SCL) is the runtime language used in QUEST for defining logics. It's pretty similar to Visual Basic and Pascal as far as I can tell, in terms of syntax. It's a fairly high level language allowing easy manipulation of files, and even execution of Windows API functions.

SCL is not only used for defining logics in a model (init, process, route, etc), but can also be used to build QUEST macros that you run using custom buttons or even remote execution through QUEST's Batch Control Lanugage (BCL). The possibilities with SCL aren't necessarily limitless, but it's a very robust language and it takes a lot of effort to run into its limitations.

SCL files are stored in text files and are not embedded within a simulation model like some other simulation packages do. This makes it easy to apply SCL code to different models, but it also means you can destroy the functionality of any number of models just by modifying a single logic file to fit a single case.

To get you started with SCL, I'll go with the old standby and just create a simple "Hello World" program to illustrate some basic SCL concepts.

To start, you first need to open a text editor and start your scl file. You can use notepad or any text editor. I prefer to use RJ-TextEd (See here) because it allows code folding and syntax highlighting; so if you have a large number of subroutines in a file you can more easily navigate the file than using notepad.

With your text editor of choice open, first create a new subroutine by defining it:

procedure hello_world()

The word "procedure" tells the scl compiler that this is a subroutine that does not return anything. If you want to return a value you replace the word "procedure" with "routine". I'll cover routines in more detail at a later time. You're also able to pass in different arguments to subroutines, but we don't need to worry about that just yet. We just want to display "hello world" in QUEST.

With your procedure name defined, we can finish defining the procedure by defining the start and end of the program:

procedure hello_world()
Begin

End

All code that you execute must fall between the Begin and End lines of the subroutine you're using. Each line of code represents one command (unless you use the line continuation character, "\").

QUEST has some decent documentation on SCL built in subroutines. From this documentation under the I/O Routines section we can find a procedure called "write" that will let us print a message to the QUEST user screen. The syntax is:

WRITE ( #unit_no, pr_expr [ , pr_expr,... ] )

where "#unit_no" is an optional argument which can specify a file or window or tcp/ip stream to write to. Disregard this for now. "pr_expr" is the message we want to write, which can be a variable of just about any type (although some types just print their memory address), though we should stick to printing simple data types( String , Real , Integer ). So the "[ , pr_expr ]" means we can specify any number of variables we want.

We don't need to pass a variable to the "write" procedure; we can pass literal strings or integer/double values as well. To write "hello world" in QUEST, we'd simply call:

write( 'hello world' , cr )

where cr is a built in QUEST variable that is basically a carriage return and line feed.

You can see I used a single quote to define a literal string, "hello world". This is the SCL compiler's preferred way of defining a literal string, but you can use double quotes if you want, as long as you are consistent in a single string definition (you can't say "hello world').

The finished procedure reads as follows:

procedure hello_world()
Begin
write( 'hello world' , cr )
End

Save your scl file into the "SCLMACROS" folder of any QUEST library you have appended. You can save with a txt or scl extension, it really doesn't matter. As long as the information is present in ASCII text the SCL compiler won't care.

We don't need to create a user button to run this macro, and so it'll probably be easier for now to just compile and run the file using BCL. To execute BCL go to File->BCL. You will be given a BCL prompt where you can type or paste a command to execute. The first line of BCL to execute is:

SCL_COMPILE 'hello_world.scl' 0

Replace 'hello_world.scl' with whatever you named your file. Don't worry about the full file path; as long as it's in an "SCLMACROS" folder QUEST should be able to find it. If the file is not found, make sure the library it's in is appended.

The next line of BCL will read:

SCL_EXEC hello_world

This line will execute the hello_world procedure stored in memory after compiling your logic file. When you run this a window should pop up in QUEST that says "hello world".

That was a bit long winded for a hello world type subroutine, but hopefully it explains how you need to define subroutines for QUEST SCL files.

Introduction Post

2008-06-03T22:01:00.000-04:00

The purpose of this blog will primarily be somewhere for me to put some of my knowledge of DELMIA QUEST (QUeueing Event Simulation Tool) out on the Internet. This is for two main reasons: one, I'd like to have somewhere to keep some of the tools I've written for QUEST, and two, maybe someone somewhere will get some value out of what I leave here.

I spend a lot of my time these days working on ways to automate the use of QUEST through QUEST's Batch Control Language (BCL) and Simulation Control Language (SCL), so that's probably what most posts will focus on for now.

I'm always looking to learn more about QUEST and simulation packages in general, so leave a comment or send an email (if that's available).

I run a Google Group on DELMIA QUEST, which at the moment doesn't have a lot of activity. If you're interested in joining go to http://groups.google.com/group/delmia_quest and join, and I'll more than likely approve you.

Happy simulating.