@Josh W. wrote:
mhousel,
Is your sequence editor still behaving badly, even when run directly (and not as an external debugging process from CVI)? Did the suggestions to uninstall/reinstall help at all?
Are you still having this trouble when using seqedit.exe as an external debugger? I set up a simple test here yesterday, and I was able to get it to work with no problems. Is there anything else unique or different about your system that might be contributing to this error?
The more information we have to work with, the better the chances of getting to the root of this problem.
Thanks!
Yes, this seems to have solved the problem. Thank you.
It's not nearly so convenient as to debug as the other method though. The operations are:
1) launch the sequence in the editor (dog slow on a 2.3GHz pentium with 1G RAM). ~15-20 seconds to the login prompt.
2) Set breakpoints in the sequence (you can't set breakpoints in your CVI project that builds a .dll).
3) Run the sequence, and stop and step through Sequence and the code, fix the problem.
4) Kill off the sequence editor and the run time CVI project (that's where you can set breakpoints but only one you step into the code in a particular file). This is also dog slow on thesame machine by the time my sequence sloses and thsn I close thw editor and it closes the runtime project. ~30-45 seconds
5) re-launch your CVI project, make the change, re-build. That seems to be relatively speedy.
6) Rinse, lather, repeat...
I didn't try a re-install since the problem was fixed by this method.
I surprised that they are unable to reproduce this. It may have to do with the overall size of the project and that it may in fact work perfectly with a simple example project. My project may be realatively large, but I have nothing for comparison and quite limited experience with TestStand.
I was an old TX Toolkit guy for many years until this year. Maybe what I'm trying to do is breaking some rules somehow?
Thanks, again. This got me back to work effectively.
Mark Housel
