ATTENTION

This FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices.


flexsim.com

Go Back   FlexSim Community Forum > FlexSim Software > Gripes and Goodies
Downloads

Gripes and Goodies Software problems and suggestions

  #1  
Old 01-11-2009
Anthony Johnson's Avatar
Anthony Johnson Anthony Johnson is offline
Manager of Product Development
 
Join Date: Jul 2007
Posts: 440
Downloads: 86
Uploads: 4
Thanks: 171
Thanked 899 Times in 288 Posts
Rep Power: 735
Anthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond reputeAnthony Johnson has a reputation beyond repute
Default Flexsim Debugger

Hey Flexsim Users,
For our next major release we are considering implementing a Flexsim debugger to help you in weeding out bugs, exceptions, modeling errors, etc. To some extent, however, we are at a loss as to what exactly that debugger should contain. Up to this point, each Flexsim user has learned his own set of tips and tricks in finding and resolving modeling issues, so I'm sure the debugging methods vary widely.

Subsequently, we would like to get your input as to what you think should be included in a good debugger. Please consider, in making your suggestions, previous modeling problems that you have encountered, how you found and fixed them, and what type of tool would have helped you in that process.

Also, for those users who have used other simulation packages, could you described how that package's debugger worked, as well as what you liked and disliked about it?

Thanks,
  #2  
Old 01-12-2009
AJ Bobo's Avatar
AJ Bobo AJ Bobo is offline
Flexsim Senior Developer
 
Join Date: Jul 2007
Posts: 108
Downloads: 8
Uploads: 0
Thanks: 23
Thanked 89 Times in 41 Posts
Rep Power: 221
AJ Bobo is a jewel in the roughAJ Bobo is a jewel in the roughAJ Bobo is a jewel in the roughAJ Bobo is a jewel in the rough
Default

While I haven't used debuggers in other simulation packages, I've used Visual Studio's debugger a lot. Here are the features from it that I use the most. (These are probably the sort of features that Anthony already has in mind, but I'm throwing them out to start the discussion more than anything.)

1) Variable watches - The debugger will show me the current values for a set of variables that I want to know about. This often removes the need to write code (that I will just remove later) to print the values of certain variables.
2) Line-by-line execution - Each line of the function executes only when I tell the debugger to advance. This way I can check the values of my variables (see item 1) before a line executes and then again after it.
3) Step-into/over - If, while step-by-step debugging, I come to a function that I wrote, I have the option of "diving" into its code to step through it or I can simply let it execute and move on to the next line in my current function. This can save a lot of time, but also gives you the option of seeing what's happening in a program in more detail.
4) Break-points - I select lines of code where the execution will automatically stop if I am debugging. If I know that a bug is occurring in a particular function, I will put a break-point at the beginning of the function and let the program run normally until that function is called. Then I step through just that function.
4a) Conditional break-points - (I haven't used this as much as the other features on the list, but it can be handy) I can assign a small function to each break-point that is executed by the debugger whenever the break-points are encountered. If the function returns true, the program execution stops. If the function returns false, the program continues running normally.
5) View call stack - The debugger shows the function that called the function I am currently debugging, and the function that called it and so on back. This can be very handy if you have a function that is called from a lot of different places in your program.
The Following 4 Users Say Thank You to AJ Bobo For This Useful Post:
Shankar Narayan (03-01-2009)
  #3  
Old 01-12-2009
Steven Hamoen's Avatar
Steven Hamoen Steven Hamoen is offline
Talumis, Flexsim Distributor, The Netherlands
 
Join Date: Aug 2007
Location: Soest, NL
Posts: 854
Downloads: 43
Uploads: 0
Thanks: 391
Thanked 661 Times in 379 Posts
Rep Power: 684
Steven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond reputeSteven Hamoen has a reputation beyond repute
Default

I think that AJ's remarks are very usefull.

Considering the Conditional break-points, those can be very handy if the error appears after a certain amount of time or a number of product handled. You can run to that point and then start debugging.

What I know from a different product from the past is the function count and the % of the execution time that a certain function is responsible for. Those can be very usefull if you want to improve or speed up your model.

Steven
  #4  
Old 01-14-2009
Kris Geisberger Kris Geisberger is offline
Flexsim Canada, Forum Moderator
 
Join Date: Aug 2007
Location: Canada
Posts: 209
Downloads: 54
Uploads: 1
Thanks: 99
Thanked 389 Times in 133 Posts
Rep Power: 451
Kris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud ofKris Geisberger has much to be proud of
Default

I like all of the suggestions so far!

I don’t have much experience with debuggers, but I figure a good tool would help me see exactly what is being executed, in sequence (hopefully in more words I understand) so that I could identify when it is not what I expected. I thought about this a bit and I tried to work from the problems toward the desired functionality.

Problems:
If there are no syntax errors and the model visuals don’t help me debug further, usually I have:
  1. code in the wrong place
    • code not executed when expected
    • code executed when expected, but then overruled by standard object behaviour functions
  2. mistakes in the code itself
    • not the right commands – not doing what I expected
    • right commands with wrong inputs
    • bad calculations or object pointers
To expand, I think a lot of model 'bugs' are a result of the user:
  1. lacking order of execution knowledge
    • expecting that a label set OnExit will be considered by a downstream object's PullRequirement
  2. misunderstanding WHEN their custom code is executed relative to standard Flexsim object behaviour functions
    • ex. TE chose a new tasksequence to work on before the user dispatched their own custom tasksequence… that they wanted the TE to chose instead
  3. lacking knowledge of what a particular object behaviour function manages, especially when it overrides what they did in a trigger
    • setting item location
    • managing a variable value
    • opening or closing ports
    • setting object state
  4. making a numerical mistake that is passed into a command
    • wrong table cell lookup
    • negative delay time on message created
    • msgparams
  5. making a bad object pointer that is passed into a command
    • setloc
    • sendmessage
    • setlabel or setitemtype
  6. creating an infinite loop
    • for loops
    • while loops
    • code in SendToPort, PullRequirement, OnMessage - releaseitem(), openoutput()
  7. mixing sendmessage vs. senddelayedmessage in 0 time

Functionality:
During step debugging, present the following information
  1. Current object name
  2. Current function name (trigger, evaluation, etc.)
  3. Current function code
  4. List of all variables passed into the current function
    • Ex. for OnMessage, if a msgparam is an object pointer show its name and highlight the object/item (or center in view) when the user double clicks on the msgparam in the list
  5. Current line of code debugger is on
  6. Local variables added to a temporary list as they are created and their values updated (until the function is complete – then the list is cleared). I guess this would include most variables passed into the function, except msgparm() and msgsendingobject. If the function is long with a lot of variables you can add a select few to a watch list, along with any Global Variables you want to watch.
  7. The actual values or object names passed into a command (not variables or more commands)
  8. Returned values of commands, especially the "get...()" commands
    Ex. Process Time evaluation
CODE VIEW:
Line1 | treenode current = ownerobject(c);
Line2 | treenode item = parnode(1);
Line3 | treenode port = parval(2);/**By Global Table Lookup*/
Line4 | /** \nTable: */
Line5 | string tablename = /**/"Table1"/**/;
Line6 | /** \nRow: */
Line7 | int row = /**/getitemtype(item)/**/;
Line8 | /** \nColumn: */
Line9 | int col = /**/getlabelnum(current,1)/**/;
Line10|
Line11| return gettablenum(tablename,row,col);
DEBUGGER VIEW:

Line7: getitemtype() on object “Textured Colored Box”, returned 14
Line7: declare integer named row = 14
<Step>
Line9: getlabelnum() on object “Combiner12”, rank 1 (named ”nextcolumn”), returned 2
Line9: declare integer named col = 2
<Step>
Line11: gettablenum() on table "Table1", row 14, column 2, returned 35.1
Line11: Process Time return = 35.1

9. Dynamic error report, similar to the system console integrated into the debugging interface.
  • NULL object pointer, node (label or table) does not exist
  • global table does not exist
  • negative delay time in senddelayedmessage()
  • negative return value in a process/setup time evaluation

10. Dynamic view of the event queue (profileevents), to give awareness of where/when future events are created and what event is next

11. Some trace of what has been executed, and where it is located (call stack?)
DEBUGGER TRACE:
LIBRARY:/Combiner>behaviour/cppfunctions/OnReceive - Start
MODEL:/Combiner12>variables/entrytrigger
*STEP DEBUG*
LIBRARY:/Processor>behaviour/cppfunctions/startsetuptime - Start
MODEL:/Combiner12>variables/setuptime
*STEP DEBUG*
LIBRARY:/Processor>behaviour/cppfunctions/startsetuptime - End
LIBRARY:/Combiner>behaviour/cppfunctions/OnReceive – End
12. Brief comments on object behaviour that is executed
Ex. Combiner - OnReceive behaviour executed
sets location of item within combiner
closeallip of combiner
executes entry trigger
*OnEntry debug*
sets the state of the combiner
manages componentlist variable table
*SetupTime debug*
13. …all in one interface I can move to monitor 2 while I have my model view on monitor 1.
  #5  
Old 01-15-2009
Alex Christensen Alex Christensen is offline
Flexsim Technical Support
 
Join Date: Nov 2007
Location: Provo, UT
Posts: 96
Downloads: 41
Uploads: 8
Thanks: 29
Thanked 141 Times in 56 Posts
Rep Power: 298
Alex Christensen is a splendid one to beholdAlex Christensen is a splendid one to beholdAlex Christensen is a splendid one to beholdAlex Christensen is a splendid one to beholdAlex Christensen is a splendid one to beholdAlex Christensen is a splendid one to beholdAlex Christensen is a splendid one to behold
Default

The kinds of bugs that bug me are the ones that cause Flexsim to crash and I usually lose some of my work. I'm not sure if it's possible to implement this, but I think it would be useful to have a Control-C or a break button that would break out of all flexscript execution so you don't have to restart if you get into an infinite loop.

Also, I would like a check on infinite recursion in Flexscript. Right now if you make a command called command1 with this code:
Code:
int x=parval(1);
msg("",numtostring(x));
command1(x+1);
On my computer, calling command1(0) gets to 170 then crashes Flexsim. The same problem exists when you have a node call nodefunction on itself.
  #6  
Old 01-20-2009
Jason Lightfoot Jason Lightfoot is offline
Flexsim Consultant
 
Join Date: Aug 2007
Location: Somerset, UK
Posts: 719
Downloads: 20
Uploads: 0
Thanks: 123
Thanked 953 Times in 446 Posts
Rep Power: 773
Jason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond reputeJason Lightfoot has a reputation beyond repute
Default

Great suggestions everyone.

I'd like to add summary statistics for code we write.

1. Number of times the code (per node) was called
a. With a breakdown showing from where it was called (with counts)

2. The amount of time spent executing the node's code.

I think this would assist debugging AND help us to focus on bottleneck chunks of code (either due to speed or number of times executed)

These execution stats would need to be toggleable I guess to cut out any overhead.
The Following User Says Thank You to Jason Lightfoot For This Useful Post:
mgiubilato (01-26-2009)
  #7  
Old 02-06-2009
Carsten Seehafer's Avatar
Carsten Seehafer Carsten Seehafer is offline
FlexSim Geek
 
Join Date: Oct 2008
Location: Ritterhude, Deutschland
Posts: 230
Downloads: 45
Uploads: 1
Thanks: 474
Thanked 320 Times in 143 Posts
Rep Power: 379
Carsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud ofCarsten Seehafer has much to be proud of
Default

I would love it if you could earmark an objekt. Everytime a peace of code interacts with this object, it'll show the line of code and step forward line by line.

With this functionality you could find out why an object isn't working as expected.



All times are GMT -6.
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 1993-2018 FlexSim Software Products, Inc.