Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Using RMV Electronics' ST400NT stepper motor controller with LabVIEW 6i.
Prospero
Member
08-27-2002 12:37 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
We are using LabVIEW 6i and a serial connection to run the ST400NT stepper motor controller from RMV Electronics (www.rmv.com). The controller ships with a C-code DLL driver and bad documentation. We discovered one nasty bug that kept crashing LabVIEW for months, the solution to which I'm posting here to help others avoid the same problem. One of the DLL functions, GetConnectedControllers, returns a comma-delimited string containing the numbers of the connected motors, plus "N" for each empty motor control slot -- it's around 50 characters long. If the string input to the Call Library Function VI that calls GetConnectedControllers is left unwired, the VI runs but the DLL function writes its return s
tring somewhere random in memory. This causes intermittant crashing of LabVIEW. The fix is to wire a dummy string constant of >100 characters into the input of the Call Library Function VI, which will be overwritten by the DLL's output and cause no harm.
tring somewhere random in memory. This causes intermittant crashing of LabVIEW. The fix is to wire a dummy string constant of >100 characters into the input of the Call Library Function VI, which will be overwritten by the DLL's output and cause no harm.
Jochen
Trusted Enthusiast
08-28-2002 02:17 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Let me comment on this: The behavior described above is very well known and documented in the NI Developer Zone and the Knowledge Base (e. g. http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/58596f5d41ce8efb862562af0074e04c?OpenDocument) but it's not a bug neither of the DLL nor of LabVIEW. What happens? If you call a DLL that returns scalar values you don't have to care about memory managment because you tell the Call Library Function (CLF) in LabVIEW which data type will be returned so it can allocate the necessary amount of memory. Things are different if the DLL returns a string or an array. In this case the CLF can't be configured to allocate the correct amount of memory because the size of arrays and strings is not fixed. That means the DLL allocates
dynamically memory in the address space of LabVIEW and there's a high probability that it overwrites important data of LabVIEW which causes LabVIEW to crash.
To avoid this just wire a string or an array to the appropriate input terminal of the CLF. The string or array should contain at least the number of charakters or values that you expect to be returned from the DLL. In this case the memory is allocated in LabVIEW, the pointer to this memory space is passed to the DLL and the DLL writes it's data to this memory space and everything works fine.
Jochen Klier
Application Engineering Group Leader
NI-Germany
dynamically memory in the address space of LabVIEW and there's a high probability that it overwrites important data of LabVIEW which causes LabVIEW to crash.
To avoid this just wire a string or an array to the appropriate input terminal of the CLF. The string or array should contain at least the number of charakters or values that you expect to be returned from the DLL. In this case the memory is allocated in LabVIEW, the pointer to this memory space is passed to the DLL and the DLL writes it's data to this memory space and everything works fine.
Jochen Klier
Application Engineering Group Leader
NI-Germany
