Make visa write return sooner

This is somewhat a continuation from this thread but I figured it was different enough to warrant another one. My question is this: I have multiple visa (serial) references in an array. I use an autoindexing for loop to write to each one. I have benchmarked the VISA write function and it takes 14 ms to execute when writing 68 bytes of data with a 38,400 baud rate. Because I have them in a for loop if I am using 8 serial ports, it takes over 100 ms for the for loop to complete. By this time, the hardware has expected another write to have happened on the first serial port, but because the subsequent writes (which are in serial..ha..ha.) take so long to execute, it hasn't written again. I know one solution is to put them in parallel, but I am trying to avoid spawning off threads on a PXI chassis based on the number of serial connections I have. This not only complicates the serial communication, but greatly complicates my application because then I would need to manage a dynamic number of queues being used to pass data to my host communication thread.
As a side note, I have tried both synchronous and asych writes.
Is their any way to communicate via serial, maybe on a lower level than visa, so it just sticks the data in a transmit buffer and leaves it there for the hardware to manage, rather than waiting for what looks to be a return after the data has been sent.
CLA, LabVIEW Versions 2010-2013

Jeff Bohrer wrote:
Well, the async writes should be about as fast as you can go. but the math (14mS for 68 bytes at 38400 Baud) seems off. How are you connected to the PXI device. I'm thinking a chassis controller might have less latency than say a MXI bridge. You aren't doining anything silly like re-initing the VISA session right? Put a conditional probe on the session in- is it valid?
Currently I'm not sure how I am connected. However, I can say that no, I am not opening and closing the session in the loop. I made a test program that is just visa open, loop with visa writes, then visa close outside the loop. I have also verified the string truly is 68 bytes and there aren't extra characters in there I'm missing, or something like that.
I have connected a scope up to the serial line. I put a gap of a few ms between writes so I can see where one transmission ends and the next one starts when looking at the scope. If I (on the scope) measure the delta time between the start and end of the transmission, it's ~19.4 ms. If I calculate 68 bytes*8 bits/byte + 3 bits for start stop parity / 38400 baud I get .0142 seconds or 14.2 ms. Is this calculation correct? The result is very close to what my benchmarking of the Visa Write is showing. Also, I'm curious of the 5 ms discrepancy between the delta t on the scope and the visa function time to execute. Any more thoughts?
CLA, LabVIEW Versions 2010-2013

Similar Messages

Re: Keitheley USB GPIB visa write returned vi_error_rsrc_nfound

"Can you explain why VISAIC works and labview does not?"
Visaic is a 32-bit application and you are using 64-bit LabVIEW. There is no passport for tulip in 64-bit VISA so there is no way to access the gpib-32.dll that the Keithley USB GPIB driver has.

I have left similar message in Keithley forum so far 20 + views no reply so far.
I have replace the keithely driver with 3.12.1 found in their website instead of what I was using in the CD that came with the adapter. but still the same behavior.
I just downloaded VISA 14.0.1 and still the same.
I launched the NI-VISA wizard and on the USB - Device Selection it recognize the adapter as Keithley model KUSB-488B. but when I choose Install the generated files on this computer I got an error dialog.
first time
got an resource error dialog
second attempt go this error dialog
"An Error has occured that has prevented the driver from being installed on your computer. One reason for this error may be because you lack the proper privileges to install this driver. You may need to log in as administrator to complete this operation"
third attmpt no error
launch NI-MAX and now it has the USB show up on the Device and Interface list.
the device show up as USB0::0x05E6::0x488B::NI-VISA-4003::RAW in NI-MAX
launch VISA Interactive Control now the three device GPIB0::9::INSTR, GPIB0::20::INSTR, and GPIB0::22::INSTR are replace by USB RAW Resource and with only one entry so I can no longer send command to each individual device thru input/Output. the same address show up in NI-MAX is also in there USB0::0x05E6::0x488B::NI-VISA-4003::RAW.
attempting the same labview visa write and visa read using GPIB0::9::INSTR as input because I don't know where USB0::0x05E6::0x488B::NI-VISA-4003::RAW is getting routed still get the same error BFFF0011 insufficient location information

Serial VISA 'Write' -why is it slow to return even with large buffer?

Hi,
I'm writing a serial data transfer code 'module' that will run 'in the background' on a cRIO-9014. I'm a bit perplexed about how VISA write in particular seems to work.
What I'm seeing is that the VISA Write takes about 177ms to 'return' from a 4096 byte write, even though my write buffer has been set to >> 4096.
My expectation would be that the write completes near instantly as long as the VISA driver available buffer space is greater than the bytes waiting to be written, and that the write function would only 'slow down' up to the defined VISA timeout value if there was no room in the buffer.
As such, I thought it would be possible to 'pre-load' the transmit buffer at a high rate, then, by careful selection of the time-out value relative to the baud rate, it would self-throttle once the buffer fills up?
Based on my testing this is not the case, which leaves me wondering:
a) If you try to set the transmit buffer to an unsupported value, will you get an error?
b) Assuming 'yes' to a, what the heck is the purpose of the serial write buffer? I see no difference running with serial buffer size == data chunk size and serial buffer size >> data chunk size??
QFang
CLD LabVIEW 7.1 to 2013

Hi, I can quickly show the low-level part as a png. It's a sub-vi for transferring file segments. Some things like the thin 'in-line' VI with (s) as the icon were added to help me look at were the hold-up is. I cropped the image to make it more readable, the cut-off left and right side is just the input and output clusters.
In a nut-shell, the VISA Write takes as much time to 'return' as it would take to transfer x bytes over y baud rate. In other words, even though there is suppused to be a (software or hardware) write and read buffer on the com port, the VISA write function seems to block until the message has physically left the port (OR it writes TO the buffer at the same speed the buffer writes out of the port). This is very unexpected to me, and what prompted me to ask about what the point is of the write buffer in the first place? -The observations are on a 9014 RT target built in serial port. Not sure if the same is observed on other targets or other OS's. [edit: and the observation holds even if transmitting block-sizes of say 4096 with a buffer size of 4096 or 2*4096 or 10 * 4096 etc. I also tried smaller block sizes and larger block sizes with larger still buffers. I was able to verify that the buffer re-size function does error out if I give it an insane input buffer size request, so I'm taking that to mean that when I assign e.g. a 4MiB buffer space with no error, the write buffer actually IS 4MiB, but I have not found a property to read back what the HW buffer is, so all I have to base that on is the lack of an error during buffer size setting.) [\edit\]
The rest of the code is somewhat irrelelvant to this discussion, however, to better understand it, the idea is that the remote side of the connection will request various things, including a file. The remote side can request a file as a stream of messages each of size 'Block Size (bytes)', or it can request a particular block (for handling e.g. re-transmission if file MD5 checksum does not match). The other main reason for doing block transfers is that VISA Write hogs a substantial ammount of CPU, so if you were to attempt to write e.g. a 4MiB file out the serial port, assuming your VISA time-out is sufficiently long for that size transfer, the write would succeed, but you would see ~50% CPU from this one thread alone and (depending on baud rates) it could remain at that level for a verrry long time. So, by transferring smaller segments at a time, I can arbitrarily insert delays between segments to let the CPU sleep (at the expense of longer transfer times). The first inner case shown that opens the file only runs for new transfers, the open file ref is kept on a shift register in the calling VI. The 'get file offset' function after the read was just something I was looking at during (continued) development, and not required for the functionality that I'm describing.
QFang
CLD LabVIEW 7.1 to 2013

Can´t access my files on Creative Cloud. "Page temporarily unavailable. We will return soon." "We are working quickly to resolve the problem and apologize for the delay. Check back later or visit our website for status updates. In addition, you can get he

Hello,
For a few days I have been trying to access my files on Creative Cloud web without success. I´ve got this message only:
"Page temporarily unavailable. We will return soon."
"We are working quickly to resolve the problem and apologize for the delay.
Check back later or visit our website for status updates.
In addition, you can get help in the forums of the Creative Cloud.
Thank you for understanding!"
(I used Google Translate)
Somebody help?

You do not need ?&promoid=KRUVP at the end of the url but it should not matter.
One thing to check is if your hosts file is modified. Open the Command Prompt and type: notepad %systemroot%\system32\drivers\etc\hosts
This will open a read-only copy of your host file in Notepad. Are there any entries in this file regarding adobe.com?
The other thing you can do is open the Developer Tools in the Chrome browser. On Windows press Ctrl + Shift to open them. Switch to the Network tab. Reload the page by pressing Ctrl + r. Check for any 4xx or 5xx errors which should be colored red.
Post screenshots of your results or send me a private forum message with the information.

How do I input multiple string constants into VISA Write

I am trying to put in multiple string commands into VISA Write to control a motor arm. However, when I use "concatenate strings" to link together my multiple string constants, only the first command is executed, and neglects the other commands below it. Should I be using something other then "concatenate strings" or do I need to use a delay so that the next command executes when the one before it is finished? Help.

Concatenate strings should work or just use one string constant with multiple lines. The problem you're having could be that the instrument requires some sort of delay but without details on the instrument, only you or the vendor can answer that. Some instruments will have a queue and others won't. The other possiblity is that you need some kind of termination character between commands. This might be a carriage return for a serial instrument or the ; character for a GPIB one. Check the instrument manual or provide the make and model and maybe someone here has some experience with it.

Visa write in Modbus

Dear All,
I am communicating a device on modbus protocol.
i have kept it under observation for 2-3 days.
I am able to communicate it properly til then, but after that 2-3 days time out error comes.
Setup is as follows:
i have connected the labview program on COM5, have used a virtual com port pair software to transfer its data to other port(name is com0com) say on com4.
now this com 4 is connected to the instrument, and also i can observe the number of bytes transmitted and received with the slave.
Till 2-3 days the bytes are transfered and received also, but after that the transmitted bytes doesnt increase, so i debugged in the modbus library of labview,
In MB Serial Transmit vi bytes are also written on the port as the return count (8) is given on visa write vi .
then also the counter for transmitted bytes doesnt increase.
I am not able trace where the exact problem is,
any suggestions..
Regards,
Shrek

Hello,
The only fault I know was in the modbus Slave library regarding coils, however that one has probably been fixed a while ago i guess, and is easy to fix yourself. The master library however works like a charm
If the problem persists, these could be some options?
1 - ignore that virtual com port software and connect directly. If that works long-term you know whats wrong
2 - If that not works, run a little bench test on the equipment. Speed up the communication and see how the instrument behaves. Try writing a lot of holding registers and see the handling of thoes, and the time delay before the instrument answers. Some instruments may react terrible after a while under pressure, and may have some buffer issues, or do not keep up but still acknowledge that the registers have been set, but internally it processes the data afterwards. giving these slower instruments some processing time might solve something. If this crashes before 2-3 days you might know the fault
3 - A work around if still stuck is re-establishing the communication when it times out. If that doesnt work its instrument related as you actually must reset the instrument?
My feeling points towards point 1
Hope this is of any help.

Why do I receive error -1073807339 VISA Write

I have a LV app built using LV2010 SP1 on a WinXP 32-bit machine. The app uses VISA to communicate serially through a RS232 to USB adpater to a pump. I can run the compiled app (exe) on another Win XP 32-bit machine without error. But the app generates "error -1073807339" with a VISA Write VI (timeout before completion) when run on Win7 64-bit machine. I have verified that both WinXP machines and the Win7 machine all have the NI device drivers installed (NI VISA 5.0.3), the LV2010 Run-Time engine, and the RS232-USB device drivers.
I have investigated sources of the timeout error and tried increasing the timeout with no success. I have also verified port settings, although the app is
identical between all machines.
I have verified that the installation on the Win7 64-bit machine was done using admin rights and files were installed correctly.
I feel like I must be missing something, so I'd appreciate some suggesitons.
Thanks
Dan

Can you communicate to the device on the Win 7 machine using hyperterminal or some some other communication program? Make sure that you have basic communication and it isn't some strange Win 7 thing. Are you runnign Win 7 64-bit? If so make sure you use the correct drivers.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

How to make a Carriage Return in a Word-Table by OLE Automation

I generated a Table in a Word-Document by using the OLE2 Interface.
After that I wrote a Text in the first cell of the table.
Now I want to make a Carriage Return to write another Textline in the same Cell.
But first i must move the cursor to the end of the Text.
I haven't already figured that out.
Can someone Help me?
I tried this but then the Cursor moves to the Begin of the second Cell in the same row.
*Writing the Text in the Cell
GET PROPERTY OF o_cell 'Range' = o_range.
SET PROPERTY OF o_range 'Text' = wa_anschr-ename.
*Move Cursor
GET PROPERTY OF o_cell 'Range' = o_range.
GET PROPERTY OF o_range 'End' = ld_pos.
SET PROPERTY OF o_range 'Start' = ld_pos.
CALL METHOD OF o_range ' Select'.

I don't know about your suggestion.
I solved the Problem with that Method:
CALL METHOD OF o_selection 'EndKey'
EXPORTING
#1 = '5'.
CALL METHOD OF o_selection 'TypeParagraph'.
The Parameter "5" ist the VB Constant wdline...
Now it works and I'm happy

How to make "visa find resource" working with Agilent device

I am trying to use Agilent 82357B GPIB device with LabVIEW for instrument control.
I have checked:
1.       NI-VISA (ver 5.1.1) is the primary visa by checking visa.dll properties under windows\system32 folder
2.       Enable NIVISATulip.dll in NI Max Explorer
3.       Enable the Agilent libraries to work with NI 488.2 in Agilent IO library (ver 16).
I am able to communicate with the instrument in Max Explorer and talk to the instrument in LabVIEW with VISA write for almost all commands.
But I can NOT make one particular visa function (Visa find resource) working with Agilent 82357B GPIB.
With NI USB GPIB device, the same code above can find attached instruments as below, where GPIB1 is the Agilent device and GPIB0 is the NI device.
I have no clue on how to make “visa find resource” working with Agilent device.
Please help.
Solved!
Go to Solution.

Quick question. Did you also enable 488 support in Agilent?
If that does'not work try this. and well see if you found a bug
Jeff

VISA Write hangs after running OK for a while

VISA Write function (VISA abc W) in my VI runs OK, with a Return Count of 4, for a while (100's to 1000's of times) then it hangs. The Return Count from this function is then 0. The Error In and Error Out show no errors. Clicking HIGHLIGHT EXECUTION shows the output wires from the VISA Write as colored grey, while everything else has normal color.
Clicking the VI red ABORT button, or any of the sub VIs red ABORT buttons, fails to abort or reset the VI even after 20 minutes. Task Manager will stop LabVIEW, but then LabVIEW will not start up again without shutting down and restarting the computer. Changing to a different Windows XP computer and a different PCI-GPIB, NI-488.2 board, as well as reinstalling LabVIEW 7.0, or using a different LabVIEW 7.0 serial number, has not solved the problem.
Thank you for your help.

Thanks for your reply. Attached is a PowerPoint file that shows info on our computer and LabView, and a For Loop
(Slide 3) that runs the VIs addressing one of our instruments (Hart 1590 Super Thermometer). Slide 4 shows the
block diagram that is pretty much as downloaded from National Instruments. The block diagrams for each of the
colored sub VIs contains a sub VI having a VISA abc W function as shown in Slide 5. The only places this VISA
function hangs is in inside the While Loop, inside the yellow Meas. Status. VI or the blue Read Meas. VI. The
Meas. Status. VI sends "new", and the Read Meas. VI sends "tem" to the Hart instrument.
Also attaced are the VIs for the Measurement Status and the Read Measurement. In the course of trying to fix this
problem I've added various time delays of 50, 100 msec, up to 1 sec, thinking that the Hart needed more time to
respond before receiving another command; none of this improved the situation. I added indicators and arrays to
capture the last several strings that were input to the VISA function, but I saw nothing unusual. All I've been
able to determine is that the VISA abc W function hangs as described in my posted message.
Attachments:
VISA Write Hang 9-15-05.zip ‏282 KB

Datasync.Write:return code from activesync_setup_5.pyc:1

Hi all,
I am testing Mobility Service 2.0.
Test server is a sles11sp3 with nothing else running. Placed in dmz with GroupWise server on lan.
Log snip:
Wed Feb 12 22:22:56 CET 2014: Datasync.Write:executing: MUSER='datasync_user' MUSERPASS='******' /opt/novell/datasync/syncengine/connectors/mobility/cli/postgres_setup_1.sh
Wed Feb 12 22:23:43 CET 2014: Datasync.Write:return code from postgress_setup_1.sh:0
Wed Feb 12 22:23:43 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/odbc_setup_2.pyc
Wed Feb 12 22:23:43 CET 2014: Datasync.Write:return code from odbc_setup_2:0
Wed Feb 12 22:23:43 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/mobility_setup_3.pyc ...
Wed Feb 12 22:23:44 CET 2014: Datasync.Write:return code from mobility_setup_3.pyc:0
Wed Feb 12 22:23:44 CET 2014: Datasync.Write:executing: /opt/novell/datasync/syncengine/connectors/mobility/cli/enable_setup_4.sh
Wed Feb 12 22:24:07 CET 2014: Datasync.Write:return code from enable_setup_4.sh:0
Wed Feb 12 22:24:08 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/mobility_setup_5.pyc --provision 'ldap' --galuser 'claus' --block false --selfsigned true --path '' --lport '443' --secure true
Wed Feb 12 22:24:13 CET 2014: Datasync.Write:return code from activesync_setup_5.pyc:1
Wed Feb 12 22:24:13 CET 2014: Datasync.Write:stdout on error:
Wed Feb 12 22:24:21 CET 2014: Datasync.GetAllStaticInterfaces:static IP info: ["eth0"]
Wed Feb 12 22:24:21 CET 2014: Datasync.GetAllipInterfaces:ip is 172.16.0.80
Wed Feb 12 22:24:22 CET 2014: Datasync.GetAllStaticInterfaces:Mapping of IP addresses and network devices: $["172.16.0.80":"eth0"]
Wed Feb 12 22:24:22 CET 2014: Datasync.GetIPAddr:First IP address 172.16.0.80
Wed Feb 12 22:24:22 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/groupwise_setup_6.pyc --keypath '*****' --lport '4500' --lip '172.16.0.80' --version '802' --soap 192.168.0.4 --key '*****' --sport 7191 --psecure 'no'
Wed Feb 12 22:24:26 CET 2014: Datasync.Write:return code from groupwise_setup_6.pyc:1
Wed Feb 12 22:24:26 CET 2014: Datasync.Write:stdout on error:
Wed Feb 12 22:24:28 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/start_mobility.pyc
Wed Feb 12 22:24:41 CET 2014: Datasync.Write:return code from start_mobility.pyc:1
Wed Feb 12 22:24:41 CET 2014: Datasync.Write:stdout on error:
Wed Feb 12 22:24:46 CET 2014: Skipping Customer Center Configuration.
Any ideas?

Hi,
returning to this.
Since last:
- Got 2.0.1 iso: No change
- Tried increasing ram: No change
- Test installed on an alternative vm guest on same subnet as GroupWise server: Succes
So I guess it must some kind of networking issue:
- I am installing on a dmz vm guest
- Checked my firewalls: No packets seems to get blocked
- Checked the soap interface from my mobility test server http://<groupwise-ip>:7191/soap, which returns POA response as expected
From install.log:
Wed Mar 26 21:48:14 CET 2014: Datasync.Write:executing: python /opt/novell/datasync/syncengine/connectors/mobility/cli/mobility_setup_5.pyc --provision 'groupwise' --galuser 'admin' --block false --selfsigned true --path '' --lport '443' --secure true
Wed Mar 26 21:48:16 CET 2014: Datasync.Write:return code from activesync_setup_5.pyc:1
Any suggestions?
What is done is this step 5?
Originally Posted by konecnya
In article <[email protected]>, Clausbc wrote:
> Hi,
> sorry for being unclear:
A trick I learned that helps me get better support response as well as
reducing the number of times I need to use support, is to think through
what will support (of any kind) need to know to help. Just doing that
exercise speeds the whole process up.
> - New install on sles11sp3 x64 virtual guest, 1G of ram
ouch, that is rather tight and might be low enough to cause you some
grief. 2GB has worked well enough for small deployments for me, though I
have had to push up to the official minimum of 4GB once some real load
got placed on it.
I would recommend getting that box up to 2GB and try the install again.
> - Log snip is from install.log in the /var/log/datasync/
> - GMS never worked on this test install
> - Haven't found any clues myself in messages
OK, that helps put a context on things.
> - Yes SOAP connection is opened, has been verified during wizard at the
> trusted application step
Was this run on this Mobility server? If not then do test from this
Mobility VM. A to make sure the DMZ to LAN route lets it through as well
as the SLES firewall on the Mobility server.
Andy of
KonecnyConsulting.ca in Toronto
Knowledge Partner
http://forums.novell.com/member.php/75037-konecnya
If you find a post helpful and are logged in the Web interface, please
show your appreciation by clicking on the star below. Thanks!

Why does visa write hang with Labview 2009 instrument drivers.

I'm having an issue with a code package that I'm running. The pacakge is very complex and was written by someone other than me. It runs fine while using the labview 8.5 drivers, however, when the 2009 instrument drivers are install there is a visa write call to an instrument where the software will hang up at the VISA write VI. I tried setting the timeout attribute but that makes no difference. I would expect that if the visa write did not work, that it would time out with an error instead of hanging up.
Some additional information. The instrument is an EPM which is on a GPIB bus with other instruments. When I place the EPM2000 on a serparate bus this problem goes away, but I want to be able to operate on the same GPIB bus.
Has anyone experienced a similar problem? What can I try to help troubleshoot the problem. I tried opening NI Spy but that shows no activity going on.

Hi Steve,
My apologies, when you said instrument drivers I assumed you were refering to the individual drivers for your instrument. Were you refering to the VISA drivers? If so, the latest version of these is 5.1.1 which can be downloaded here: http://joule.ni.com/nidu/cds/view/p/id/2659/lang/en.
Also are you able to communicate with this device using the test panels in Measurement & Automation Explorer? There is also a tool called NI IO Trace (or it may still be called NI-SPY in 2009) that can be opened from MAX that monitors all GPIB commands sent and received on the machine. Getting a log of the commands when the hang occurs may help to diagnose it.
It is possible this issue could be caused by opening and closing the VISA reference frequently in the code such as in a loop iteration. Is this is case in your code?
Justin D
Applications Engineer
National Instruments
http://www.ni.com/support/

GPIB locks up after about 15 minutes with a VISA Write Timeout Error

I am using GPIB to control two electronic loads. After about 15 minutes of runtime on the program, the GPIB communication locks up. A probe reveals an error message about a Visa Write Timeout. When this occurs, I have to stop the program, cycle the power on the two loads, and then restart the LabView program. When addressing the loads, I use the same routine every time. 1) Initialize communication, 2) Send command/request, 3) Close communication. I thought I might have been overloading the GPIB bus, so that's when I added the close command after each sequence. However, it didn't seem to make a difference. Could there be a compatability issue with the GPIB of the loads and the NI GPIB or Windows version? (I'm using XP and LV 10) The electronic loads are older models, so I'm not sure how that impacts this scenario.

Hi kcarbon80,
As this thread is over 2 years old, I do not know what solution was found for the previous problem being addressed, if any. However, if the device is locking up in the middle of your program, you may want to try clearing the device programmatically using the DevClear.vi that comes with the NI 488.2 driver.
I hope this helps.
Best Regards,
Thomas B.
National Instruments
Applications Engineer

How can i make a soft return with pages shift enter does not work!

how can i make a soft return with pages shift plus enter does not work!!

On full keyboards with a numeric keypad, the key above the right shift is "return" & the one on the numeric section is "enter." On a Mac (or Apple IIgs ) they do have separate functions. On the "mini" keyboards, both names are on the same key, but "enter" is written in smaller letters. I'll have to check to see how that works on another Mac later today.

VISA Write differs between TS Development System and LV Run-Time Engine

Hi all
I made an application on LabVIEW to test BERs (Bit Error Rates), and I used VISA Write between two COM ports to exchange data.
Everything works fine using just LabVIEW.
Afterwards, I used TestStand to call my application (VI). The LabVIEW adapters from TestStand were set to Development System by default, and everything works OK!!
Finally, I needed to disable the development system, and set the LabVIEW adapters from TestStand to LabVIEW Run-Time Engine and I notice that the speed of the data exchange between the two COM ports decreased dramatically.
The only difference was the speed...because all the data (changed slowly in this case) arrived correctly on the other COM port too.
The symptom was the same as decreasing the baud rate...but the baud rate and all the other configurations remained the same. The only difference was the change between Develpment System to Run-Time Engine to notice this decreased speed between the exchanged data using VISA Write.
Any solutions for this?
Thanks in advance
Joao
Solved!
Go to Solution.

Joao,
you state that using the LV Developement System as execution platform for your LV code modules result in faster datatransfer between the COM ports than using the LV Run-Time Engine.
So i am pondering: Does this refer to TS at all?
Please check the following:
Run you communication using a sole LV application in LV Developement System. This should be fast. Now build an executable of this application and run that one. Do you see the same behavior?
If there is no difference in a sole LV approach, there have to be some settings in the TS approach making this slow. So please let us know:
Are there different modules involved in that data transfer (which in fact points to the reply Christophe made)?
What about loading/unloading options of the modules?
How big is the hierarchy of the modules, e.g. is it necessary for the RTE to load stuff the Dev Env has already in memory due to loading a lvproj.......?
Could you provide a simple example sequence+modules showing this behavior?
What versions of LV and TS are you using?
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Make visa write return sooner

Similar Messages

Maybe you are looking for