Error 113 - UDP

I am currently using Labview 8.20
I am reading a text file and sending the contents of that file using UDP. The file is big and I get the
Error 113. " A message sent on a datagram was larger than the internal buffer or some other network limit,
or the buffer used to receive a datagram was small that the datagram itself". If I use a small file, it works.
I am fairly new to Labview and I just modified the code in the Examples for the UDP Sender and
I am using the UDP Receiver example.
I am using the Read From Text File VI and connected it's output text to the UDP data in.
Any ideas?
Jaime

Hi Jaime,
First of all, are you positive this is LabVIEW 8.20? I have noticed a similar issue that was resolved in LabVIEW 8.0... Are these two PCs both on the same OS and both with LabVIEW 8.20?
Assuming so, how large of a file are you transmitting using UDP? Have you seen what the threshold might be for causing this error? Also, try increasing the max bytes/read and see if that helps.
Sam
-Sam F, DAQ Marketing Manager
Learn about measuring temperature
Learn how to take voltage measurements
Learn how to measure current

Similar Messages

Increase UDP sending size over 64k bytes and get error -113,sending buffer not enough

Dear all,
I have a case that I must send a data over 64k bytes in a socket with UDP . I got a error-113 shows "A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram was smaller than the datagram itself.".I searched for this issue and got the closest answer as below:
http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D?OpenDocument
It said I have to change buffer size with Wsock.dll. I used the same mathod to increaes the send buffer to 131072 bytes by choice optionname to so_sndbuf (x1001) and give it value with 131072 and it worked fine without error. However I still got an error 113 while sending data with " UDP Write.vi ". It seems UDP write.vi reset the buffer size? Are there any other things cause the error?
I attached example code. In UDP Sender.vi you can see I change send buffer size to 131072 and send date included a 65536 bytes data.There is also a UDP receiver.vi and there is some missing VI which you can get from the LINK. But it's not necessary.
Attachments:
UDP Sender.vi ‏14 KB
UDP Receiver.vi ‏16 KB
UDP_set_send_buffer.vi ‏16 KB

The header for a UDP packet includes a 16 bit field that defines the size of the UDP message (HEADER AND DATA)
16 bits limits you to a total size of 65635 bytes, minus the header sizes; a minimum of 20 bytes are required to define an IP packet and 8 bytes for UDP leaving an effective data payload of 65507
bytes.
LabVIEW is not the issue...
http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure
Now is the right time to use %^<%Y-%m-%dT%H:%M:%S%3uZ>T
If you don't hate time zones, you're not a real programmer.
"You are what you don't automate"
Inplaceness is synonymous with insidiousness

UDP ERROR 113

DEAR READERS
                                   I AM A BEGINNER LEVEL LABVIEW APPLICATION ENGINEER. I AM TRYING TO COMMUNICATE TWO SYSTEMS(MY LAPTOP AND COMPUTER) USING UDP PROTOCOL IN LABVIEW. I HAVE CODED THE REQUIRED IN BOTH THE SYSTEM. I AM FACING ERROR WHEN I RUN BOTH THE SYSTEM SIMULTANEOUSLY.
                                    THE ERROR NUMBER IS 113 AND 56 SOMETIMES.
ERROR 113 SAYS THAT THE MESSAGE SENT ON A DATAGRAM SOCKET WAS LARGER THAN THE INTERNAL MESSAGE BUFFER OR SOME OTHER NETWORK LIMIT OR THE BUFFER USED TO RECEIVE A DATAGRAM WAS SMALLER THAN THE DATAGRAM ITSELF.
         WHAT SHOULD I DO TO REMOVE THESE ERROR 56 AND ERROR 113???

Dear Reader,
I regret for the caps letter. I am sending you my code UDP try and udp try receive. I am facing 113 error.You can run it simultaneously in two system and see to yourself. I am a beginner in LabVIEW. I am happy to get your help.
Attachments:
udp receive try.vi ‏13 KB
udp try.vi ‏54 KB

Failed to read the table scslmthresh: error = 113

I'm continously getting the above error (Failed to read the table scslmthresh: error = 113) on a new sun cluster 3.2 on two T5240s with a 2540 as their storage. I've searched for this error but I cannot find any information on it. Anyone know what this is??
java[1935]: [ID 513556 daemon.warning] Failed to read the table scslmthresh: error = 113
I do have the cluster telemetry services running and a few storage resources, but nothing big yet. This error happens about every 2 hours, but the timing is not exaclty consistent.
thanks for any insight.

I figured out that this error definitely has to do with reading/writing information to the telemetry resource/data service, so I removed mine completely and re-installed it using the clsetup (option 8, then option 2). That seems to have removed the error. I'm guessing a Java patch changed something that the telemetry service didn't like.

Linux Error: 113: No route to host

After completeing 3.1 in the installation guide I jump down to chapter 4, but I can't get the web interface to work.
It doesn't matter how I access the URL, I've tried both http://localhost:8080/htmldb and http://realhostname:8080/htmldb/ with same result, no data at all, the connection is closed directly.
I've checked listener.log and found this:
02-NOV-2005 01:01:02 * http * (ADDRESS=(PROTOCOL=tcp)(HOST=10.8.0.22)(PORT=2556)) * handoff * http * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12571: TNS:packet writer failure
TNS-12560: TNS:protocol adapter error
TNS-00530: Protocol adapter error
Linux Error: 113: No route to host
02-NOV-2005 01:01:23 * http * (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=33183)) * handoff * http * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12571: TNS:packet writer failure
TNS-12560: TNS:protocol adapter error
TNS-00530: Protocol adapter error
Linux Error: 113: No route to host
02-NOV-2005 01:02:54 * service_update * XE * 0
02-NOV-2005 01:03:01 * http * (ADDRESS=(PROTOCOL=tcp)(HOST=X.Y.Z.W)(PORT=33509)) * handoff * http * 12518
TNS-12518: TNS:listener could not hand off client connection
TNS-12571: TNS:packet writer failure
TNS-12560: TNS:protocol adapter error
TNS-00530: Protocol adapter error
Linux Error: 113: No route to host

Problem located (as usual after the 3 hours it took me to find the forum and post about it).
Using netstat and lsof I found that XE not only binds to 1521 and 8080, but also to port 33172 and since iptables blocks everything it got "No route to host".
The question is if 33172 is static or just a randomly chosen port number.

GoldenGate extract issue - TCP/IP error 113 (No route to host)

Hi All,
I have created a new replicat process on a new server. The old server is to be de-commissioned. after I created the replicat process on the new server (I copied the replicat prm file from the existing server - which is to be de-commissioned to new server and changed old encrypted password with new one and DISCARDFILE location), I modified the extract parameter file on source server. I changed RMTHOST and RMTTRAIL from older server name to new server name and old location to new location. once done , I stopped the extract and ran below command:
ADD RMTTRAIL /u01/app/ggs/dirdat/db, EXTRACT Ext1
and then started the extract process after which I am getting this error:
*2012-03-16 02:24:39 GGS ERROR 150 TCP/IP error 113 (No route to host).*
*2012-03-16 02:24:39 GGS ERROR 190 PROCESS ABENDING.*
I can very well ping both servers from both source and target. Any thoughts?
-Onkar

got the answer. It was firewall issue. When i turned the firewall down "service iptables stop", everything was smooth. I have raised request with the proper team to add the source ip in the target system firewall.
-Onkar

Kiethly 2400 Error 113 "Undefined Header"

Hello,
   I am currently using a Keithley 2400 both as a current source and as a measuring device. The program I am running is based on the Keithly 24xx drivers (http://sine.ni.com/apps/utf8/niid_web_display.download_page?p_id_guid=25B255F3AA83660EE0440003BA7CCD71).
The program works perfectly for about 30 seconds of data collection, then shows Error 113 Undefined Header, then begins to work again after a brief interruption. The error will then appear randomly after that. Does anyone know what is causing this error and how to stop it? My code can be found attached to the message
I ran NI SPY and the following was highlighted red: >
697. viWaitOnEvent (GPIB0::16::INSTR (0x02D08828), IO_COMPLETION, 0, 0, 0x00000000)
> Process ID: 0x00000874         Thread ID: 0x00000D10
> Start Time: 15:31:10.343       Call Duration 00:00:00.000
> Status: 0xBFFF0015 (VI_ERROR_TMO)
from 697 to 708
The lines before it were:
695. VISA Write ("GPIB0::16::INSTR", ":ARM:COUN 1;:TRIG:COU...")
Process ID: 0x00000874         Thread ID: 0x00000FA4
Start Time: 15:31:10.328       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)
696. VISA Write ("GPIB0::16::INSTR", "ARMOUR IMM;:ARM:TIM...")
Process ID: 0x00000874         Thread ID: 0x00000FA4
Start Time: 15:31:10.328       Call Duration 00:00:00.015
Status: 0 (VI_SUCCESS)
the lines after it were:
709. viWaitOnEvent (GPIB0::16::INSTR (0x02D08828), IO_COMPLETION, 0, IO_COMPLETION, 0x02DA2878)
Process ID: 0x00000874         Thread ID: 0x00000D10
Start Time: 15:31:10.343       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)
710. Completing viWriteAsync (GPIB0::16::INSTR (0x02D08828), 0x04045CD1, "ARMOUR IMM;:ARM:TIM...", 65)
Process ID: 0x00000874         Thread ID: 0x00000D10
Start Time: 15:31:10.343       Call Duration 00:00:00.000
Status: 0 (VI_SUCCESS)
Attachments:
Source_Current_Meas_Volt_Single_Read.vi ‏68 KB

The error occurs when the VI code is at the "read single" point of the VI. When I watch the sub VI's, the progression is that under the read single VI, it occurs at the read multiple points VI, and under that VI with error 1073807339 at the Fetch Measurements VI, and under that VI it occurs, with the same error code 1073807339 at the VISA Read and the Property Node. I have attached the spy file with just my program open, and with the Fetch program open.
Attachments:
Capture.spy ‏265 KB
capture with fetch subvi runnning.spy ‏265 KB

UDP with cRIO and error 113

Hi all,
i'm using the UDP protocol to exchange information between a PC and a cRIO; the first is the master, the second is the slave.
In the cRIO i developed a piece of code in order to realize a loopback, so that the message sent from the PC is sent back to the PC itself as it has been received, without any modification.
First, i tried sending a short message (100 B) from the PC to the cRIO; in this case, no problem at all
Then, i tried sending a long message (20 kB) from the PC to the cRIO; in the cRIO code, the error number 113 was raised when trying to send back the message to the PC (calling the UDP write function)
What can be the origin of the different behaviour between the PC and the cRIO? Seems to be a question of buffer size... Can it be dependent of the OS? How can i increase it in the cRIO?
Thanks!
aRCo

Hi aRCo,
According to Wikipedia (https://en.wikipedia.org/wiki/User_Datagram_Protocol), the max. theoretical limit for a UDP datagram is 8 bytes for header + 65,527 bytes of data (65,535 bytes in total). However, "the practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header)". The wiki article goes on to say that larger packets are possible with Jumbograms.
As for the NI documented limits of 8K, this would appear to be a LabVIEW-imposed limitation. (Perhaps this was related to an earlier limitation of the UDP protocol that has since been upgraded. If I recall correctly, the Windows version of LabVIEW also had this 8K limitation in the past.)
Perhaps NI relaxed this limit, or maybe you have jumbo packets enabled on youir PC, and this is allowing more throughput (-- of course both of these possibilities are only speculation on my part).
In any event, if you limit the UDP packet size to the documented 8K limitation, your code should probably be fine across all LV platforms. (How's that for stating the obvious..?)
Anyway, good luck with your application.
-- Dave
www.movimed.com - Custom Imaging Solutions

Linux error 113

on vmware , we have z box call rman.blobin.biz
I have installed RMNDB on it on port 1571 . listener is also running on this.
I am able to do sqlplus rman/rman@RMNDB.
rman.blobin.biz tnsnames.ora for this DB has following entries.
RMNDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rman.blobin.biz)(PORT = 1571))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RMNDB)
MODEV =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = moprddb01.blobin.biz)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = MODEV)
from this box I am able to do tnsping RMNDB as well as tnsping MODEV
there is a box moprddb01.blobin.biz which has MODEV
from that box I cna do tnsping MODEV but noy tnsping RMNDB and sqlplus rman/rman@RMNDB.
It gives me error as
ERROR:
ORA-12560: TNS:protocol adapter error
I worked with Oracle and generated Trace.
sqlnet.log is showingLinux 113 error.
Oracle is saying :
You will need to work with your local network admin and sys admin to find out what the problem
is with accessing the rman.blobin.biz node. The restrcition is occurring at the TCP layer as i
ndicated by the Linux 113 error.
we dont have onsite any Linux export or support. I set with network guy we checked port, firewall. it didnt show any issue.
I am really stuck very badly. as there is no Linux guy .
I need to do tnsping RMNDB from MODEV database box.
Any help will be appreciated.

Script started on Thu 24 Apr 2008 08:19:31 AM EDT
[root@rman ~]# uname -a^M
Linux rman.lifecell.biz 2.6.18-53.1.14.el5 #1 SMP Tue Feb 19 07:18:21 EST 2008 i686 i686 i386 GNU/Linux^M
[root@rman ~]# cat /etc/resolv.conf^M
search lifecell.biz^M
nameserver 172.16.179.202^M
nameserver 172.16.179.203^M
[root@rman ~]# ifconfig^M
eth0 Link encap:Ethernet HWaddr 00:50:56:B1:2C:07 ^M
inet addr:172.16.180.47 Bcast:172.16.255.255 Mask:255.255.0.0^M
inet6 addr: fe80::250:56ff:feb1:2c07/64 Scope:Link^M
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1^M
RX packets:55229028 errors:33 dropped:36 overruns:0 frame:0^M
TX packets:3874077 errors:0 dropped:0 overruns:0 carrier:0^M
collisions:0 txqueuelen:1000 ^M
RX bytes:1307448164 (1.2 GiB) TX bytes:497502369 (474.4 MiB)^M
Interrupt:177 Base address:0x1400 ^M
^M
lo Link encap:Local Loopback ^M
inet addr:127.0.0.1 Mask:255.0.0.0^M
inet6 addr: ::1/128 Scope:Host^M
UP LOOPBACK RUNNING MTU:16436 Metric:1^M
RX packets:4497367 errors:0 dropped:0 overruns:0 frame:0^M
TX packets:4497367 errors:0 dropped:0 overruns:0 carrier:0^M
collisions:0 txqueuelen:0 ^M
RX bytes:500146185 (476.9 MiB) TX bytes:500146185 (476.9 MiB)^M
[root@rman ~]# service iptables status^M
Table: filter^M
Chain INPUT (policy ACCEPT)^M
num target prot opt source destination ^M
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0 ^M
^M
Chain FORWARD (policy ACCEPT)^M
num target prot opt source destination ^M
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0 ^M
^M
Chain OUTPUT (policy ACCEPT)^M
num target prot opt source destination ^M
^M
Chain RH-Firewall-1-INPUT (2 references)^M
num target prot opt source destination ^M
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ^M
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255 ^M
3 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 ^M
4 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 ^M
5 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353 ^M
6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631 ^M
7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 ^M
8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ^M
9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21 ^M
10 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ^M
11 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443 ^M
12 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23 ^M
13 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ^M
14 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited ^M
^M
[root@rman ~]# hostname^M
rman.lifecell.biz^M
[root@rman ~]# cat /etc/hosts^M
# Do not remove the following line, or various programs^M
# that require network functionality will fail.^M
127.0.0.1 rman.lifecell.biz rman localhost.localdomain localhost^M
::1 localhost6.localdomain6 localhost6^M
172.16.180.47 rman.lifecell.biz rman^M
[root@rman ~]# exit^M
Script done on Thu 24 Apr 2008 08:20:38 AM EDT
This is the output

Unity_UMR error 113 &137 Event viewer

i Have problem in unity 7.0 the voice mail not recievied to the user and the error come in event viewer that as per i attached Unity_UMR event ID 113 & 137 so can any help on this issue
Thanks,

Hi Kapil,
This is generally seen if the you have MAPI CDO installed and the Exchange System Manager has not uninstalled Successfully.
A few possible reasons for this problem:
1)Uninstallation on Exchange System Manager or installation of MAPI CDO was done using Microsoft Remote Desktop.
2)There are some leftover dlls of the of the Exchange System Manager in the Unity servers.
Things that you can try to resolve this problem:
++ Use VNC Session to uninstall/install Exchange System Manager and MAPI CDO.
++ Make sure there is no emsabp32.dll and emsmdb32.dll file in the Windows\System32 directory.
++ Windows\system32\mapi32.dll should be at version of 6.5.7654.9 or higher. Or still at version 1.x. Anything in between is no good.
Hope that helps!
Regards,
Saurabh

Error deploying UDP Channel Streaming Session

All,
I'm suddenly running into an unexplained error when attempting to deploy a UDP streaming session to my veristand system. When attempting to deploy I get the attached message with an error code of -307652. According to http://zone.ni.com/reference/en-XX/help/372846A-01/veristand/vs_error_codes/ all that means is that it failed to open a connection, which is apparent... I'm completely stumped. Obviously the message isn't telling me much but to turn on more detailed explainations but I have absolutely no idea how to go about doing that. This message just popped up yesterday after the system worked fine the day before. No "code" related to the UDP system changed inbetween usages and UDP streaming had been fully functional prior to this problem. I know I have a connection through to my veristand system because command transmission works just fine (I can actuate things), but I have no idea what causes this type of error or how to go about fixing it. I've already gone through the unbelievably painful process of reinstalling EVERYTHING (Veristand, Labview, all associated device drivers and .NET) but that proved unsuccessful.
Any and all suggestions would be appreciated.
-Drew
Attachments:
Capture.PNG ‏12 KB

Hi Andy,
so in brief, yes my other LabVIEW calls to the Veristand gateway are working just fine. I am actually deploying the system through Veristand itself, not from a LabVIEW system remotely in most situations. I have however, put together a quick little remote deployment setup that does manage to deploy 100% successfully. Additionally, I am perfectly capable of sending other commands through to Veristand from the LabVIEW system. So yes, things like SetChannel and the various StimulusProfile API sections that I'm using are 100% ok. It's just the UDPChannelStreaming calls that are throwing any kind of error.
To answer your second question, I've made sure to disable any other calls to the API when trying the deployment and am experiencing the same problem. To verify this, I actually started up a Wireshark packet capture and there is no communication between my LabVIEW system and the Veristand gateway after initial connection until I send a command or attempt to deploy the UDP stream. Additionally, I was able to see the error message coming from the Gateway to LabVIEW in a TCP packet so I know the issue is on the Veristand side, not the LabVIEW side (see attached screen grab), which I really already knew, but it helps to verify.
This really sounds to me like a network issue but I've verified that our firewall allows any and all communication from a computer on the LAN to any and all other machines on the LAN to pass untouched, and everything else on our LAN is unmagaged so there is no reason we would suddenly have troubled with a UDP multicast from a network perspective.
-Drew
Attachments:
Capture.PNG ‏161 KB

Udp 發送大於64K資料產生錯誤 113 ,buffer不足

大家好
我必須用UDP送出大於64k的封包而遇到緩衝區不足的錯誤 113。查過說明發現可藉由設定Wsock.dll method: setsockopt: optionnameo_sndbuf.的方式來增加windows UDP sending buffer，但是個錯誤還是未解。詳細內容我寫在英文的討論區中
http://forums.ni.com/t5/LabVIEW/Increase-UDP-sending-size-over-64k-bytes-and-get-error-113/td-p/3051...
還請各路高手解惑，謝謝

Dear Reader,
I regret for the caps letter. I am sending you my code UDP try and udp try receive. I am facing 113 error.You can run it simultaneously in two system and see to yourself. I am a beginner in LabVIEW. I am happy to get your help.
Attachments:
udp receive try.vi ‏13 KB
udp try.vi ‏54 KB

Error 54 on udp multicast cRIO

I'm trying to get a cRIO-9075 broadcasting data over a network with UDP. I've opened the UDP multicast examples and they work fine when I run them on my development computer. When I deploy and run the examples on the cRIO controller however, I get either 'Error 54 - the network address is ill-formed' if trying to use the send/recieve example or run UDP open in read/write mode, or "Error 59 - the network is down, unreachable or has been reset" if i try to use just UDP send or UDP open in write only mode.
I'm using a valid multicast IP address that is within the multicast region (234.5.6.7 as in the example), have tried multiple ports, (0, 58432, 50001...) and have tried with my firewalls disabled, wireless internet connection and bluetooth all disabled. The cRIO is connected directly to the development PC via a straight network cable, although I'm pretty sure my network card is sorting out the crossover detection as everything else on the connection is working fine.
Does anyone have any ideas on how to debug this? I've kinda hit a brick wall here, so any help would be greatly appreciated.
Solved!
Go to Solution.

Hi Aidan,
What you said was correct, however it seems that after trying again this time I've had success transferring data. I'd doubt my code, and will be sure to post snippets next time, but as my post says I ran the labview UDP multicast example pair on the development machine, so I can only suppose a network hitch... Very strange, as sending data over the same socket with the TCP/IP example worked.
Since then things seem to be going mostly smoothly - I've been able to broadcast data from the cRIO and pick it up on the development PC. I have hit a bit of a hitch with sending datagrams of 8192 bytes ...
Spoiler (Highlight to read)
I'm getting 'error 113 - the datagram is too large for the buffer or other network limit' on the UDP recieve end. I believe 8192B is the maximum UDP packet size, and don't get any errors on write, but even increasing the socket buffer size by modifying the windows dll as per here (http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D) I'm still receiving the error. Using smaller packet sizes (e.g 540B) seems to work, but as I'm trying to maximise throughput it could pose an additional limitation. I've read 64MB is the UDP protocol maximum size, and 8192B is a labview limitation. Any ideas on this?
I'm getting 'error 113 - the datagram is too large for the buffer or other network limit' on the UDP recieve end. I believe 8192B is the maximum UDP packet size, and don't get any errors on write, but even increasing the socket buffer size by modifying the windows dll as per here (http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D) I'm still receiving the error. Using smaller packet sizes (e.g 540B) seems to work, but as I'm trying to maximise throughput it could pose an additional limitation. I've read 64MB is the UDP protocol maximum size, and 8192B is a labview limitation. Any ideas on this?
...but I suppose that's another issue.
For now I think I'll leave the cRIO on a static IP and not get hung up on this issue. Thanks for working through this with me Aidan.
For the record: the port was 58432, multicast address 234.5.6.7 as in the UDP multicast examples. development PC was XP, 2.26GHz dual core w/ 3GB RAM (limited as 32-bit), will update with ethernet card later as I'm on a different machine right now.

"HP34970A Conf Resistance.vi" causes error message -113

I'm using Labview 6.1 to read voltage, frequency, resistance and temperature readings from an HP34970A (with 34902A 16-channel multiplexer).
Every time the "HP34970A Conf Resistance.vi" is completed it causes the HP34970A to display error -113: "Undefined header. A command was received that is not valid for this instrument. You may have misspelled the command or it may not be a valid command. If you are using the shortened form of this command, remember that it may contain up to four letters. Or you may have inserted an extra colon where one is not required.".
The only thing the vi is supposed to do, is to enable the offset compensation, which it is doing (I tested that with a separate program).
Although t
here is no help file with the NI drivers for the instrument and I'm new to Labview, I would like to know if someone found a workaround for this. It is kind of annoying because the error message is accompanied with a beep of the instrument every 3s.
Thanks.

Thanks for your fast response.
I'm using the latest version of the drivers (I installed everything in the begining of Mai).
I wrote a small vi for NI Spy, just a simple 4 wire resistor measurement with "Conf Resistance.vi" at the beginning.
Unfortunately it is my first time working with LabVIEW and the VISA language, and the syntax looks correct for me. ( But I still get the -113 error.)
Here the processed commands (1 loop):
1. viGetAttribute (0x0015B920,0x3FFF018F,VI_FALSE)
Process ID: 0x0000033C Thread ID: 0x0000041C
Start Time: 14:52:09.127 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
2. viGetAttribute (0x0015B920,0x3FFF018F,VI_FALSE)
Process ID: 0x0000033C Thread ID: 0x0000041C
Start Time: 14:52:09.127 Call Duration: 00:00:00.010
Status: 0 (VI_SUCCESS)
3. viGetAttribute (0x0015B920,0x3FFF018F,VI_FALSE)
Process ID: 0x0000033C Thread ID: 0x0000041C
Start Time: 14:52:09.157 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
4. viGetAttribute (0x0015B920,0x3FFF018F,VI_FALSE)
Process ID: 0x0000033C Thread ID: 0x0000041C
Start Time: 14:52:09.157 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
5. viOpen (0x0015B920,"COM1",0 (0x0),0 (0x0),0x0017CC30)
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.469 Call Duration: 00:00:00.010
Status: 0 (VI_SUCCESS)
6. viGetAttribute (0x0017CC30,0x3FFF0171,4 (0x4))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.479 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
7. viGetAttribute (0x0017CC30,0x3FFF0171,4 (0x4))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.479 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
8. viSetAttribute (0x0017CC30,0x3FFF001A,10000 (0x2710))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.479 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
9. viSetAttribute (0x0017CC30,0x3FFF0021,57600 (0xE100))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.479 Call Duration: 00:00:00.010
Status: 0 (VI_SUCCESS)
10. viSetAttribute (0x0017CC30,0x3FFF0025,1 (0x1))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.489 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
11. viWrite (0x0017CC30,"*RST.",5 (0x5),5 (0x5))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.489 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
12. viWrite (0x0017CC30,"SYSTRES.",10 (0xA),10 (0xA))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.489 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
13. viWrite (0x0017CC30,"*IDN?.",6 (0x6),6 (0x6))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.489 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
14. viRead (0x0017CC30,"HEWLETT-PACKARD,34970...",50 (0x32),32 (0x20))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.489 Call Duration: 00:00:00.370
Status: 0 (VI_SUCCESS)
15. viWrite (0x0017CC30,"*RST.",5 (0x5),5 (0x5))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.859 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
16. viWrite (0x0017CC30,"SYSTRES.",10 (0xA),10 (0xA))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:17.859 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
17. viWrite (0x0017CC30,"FUNC "RES", (@);EN...",122 (0x7A),122 (0x7A))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:18.781 Call Duration: 00:00:00.020
Status: 0 (VI_SUCCESS)
18. viWrite (0x0017CC30,"MEAS:FRES? AUTO, (@101).",24 (0x18),24 (0x18))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:19.742 Call Duration: 00:00:00.010
Status: 0 (VI_SUCCESS)
19. viSetAttribute (0x0017CC30,0x3FFF001A,320000 (0x4E200))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:19.752 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
20. viRead (0x0017CC30,"+1.08185990E+02..",500 (0x1F4),17 (0x11))
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:19.752 Call Duration: 00:00:00.130
Status: 0 (VI_SUCCESS)
21. viClose (0x0017CC30)
Process ID: 0x0000033C Thread ID: 0x0000042C
Start Time: 14:52:21.214 Call Duration: 00:00:00.000
Status: 0 (VI_SUCCESS)
Thanks,
Dirk

Error occured in the accounting process

Dear Gurus,
Following is the error message i am getting:
Starting to account all the events created ...
ORA-06508: PL/SQL: could not find program unit being called occurred in
AP_ACCOU
NTING_MAIN_PKG.Create_Accounting_Entry<-AP_ACCOUNTING_ENGINE_PKG.do_accounting<-
APXAEREP
with parameters (&PARAMETERS)
while performing the following operation:
We have upgraded our instance from 11.5.7 to 11.5.10.2 successfully, while performing the testing after the upgrade and loading the backlog data we got the following error while running Payables Accounting Process:
Starting to account all the events created ...
ORA-06508: PL/SQL: could not find program unit being called occurred in
AP_ACCOU
NTING_MAIN_PKG.Create_Accounting_Entry<-AP_ACCOUNTING_ENGINE_PKG.do_accounting<-
APXAEREP
with parameters (&PARAMETERS)
So did a search and found that we need to apply the Patch 3801440 - ROLL UP PATCH 2 - CONSOLIDATED PATCH FOR ALL ACCOUNTING DATA CORRUPTION ISSUES
Patch 3919192 - ROLL UP PATCH ON AP.L - CONSOLIDATED PATCH FOR ALL ACCOUNTING DATA CORRUPTION I and we applied, but still the issue remains same, did further research on metalink and found 11.5.10:AP.M:PAYABLE ACCOUNTING PROCESS COMPLETING IN ERROR Patch 5930565 and applied, but after applying tired to query the database and found the following :
SQL> select status from dba_objects where object_name='AP_PREPAY_APP_EVENT_CORE_PKG';
STATUS
VALID
INVALID
SQL> select status from dba_objects where object_name='AP_ACCOUNTING_MAIN_PKG';
STATUS
VALID
INVALID
Tried to see in the database and tried to compile the packages as follows:
SQL> alter package AP_ACCOUNTING_MAIN_PKG compile body;
Warning: Package Body altered with compilation errors.
SQL> show err
Errors for PACKAGE BODY AP_ACCOUNTING_MAIN_PKG:
LINE/COL ERROR
113/9 PLS-00905: object APPS.AP_PAYMENT_EVENT_CORE_PKG is invalid
113/9 PL/SQL: Statement ignored
126/9 PLS-00905: object APPS.AP_PAYMENT_ADJ_EVENT_CORE_PKG is invalid
126/9 PL/SQL: Statement ignored
139/9 PLS-00905: object APPS.AP_PAYMENT_CANC_EVENT_CORE_PKG is invalid
139/9 PL/SQL: Statement ignored
192/9 PLS-00905: object APPS.AP_PAYMENT_CLR_EVENT_CORE_PKG is invalid
192/9 PL/SQL: Statement ignored
205/9 PLS-00905: object APPS.AP_PAYMENT_UCLR_EVENT_CORE_PKG is invalid
205/9 PL/SQL: Statement ignored
SQL> alter package AP_PREPAY_APP_EVENT_CORE_PKG compile body;
Warning: Package Body altered with compilation errors.
SQL> show error
Errors for PACKAGE BODY AP_PREPAY_APP_EVENT_CORE_PKG:
LINE/COL ERROR
1704/35 PLS-00103: Encountered the symbol "SELECT" when expecting one of
the following:
( - + case mod new not null others <an identifier>
<a double-quoted delimited-identifier> <a bind variable> avg
count current exists max min prior sql stddev sum variance
execute forall merge time timestamp interval date
<a string literal with character set specification>
<a number> <a single-quoted SQL string> pipe
1709/51 PLS-00103: Encountered the symbol ")" when expecting one of the
following:
LINE/COL ERROR
. ( * @ % & - + ; / at for mod rem <an exponent (**)> and or
group having intersect minus order start union where connect
||
SQL> alter package APPS.AP_PAYMENT_EVENT_CORE_PKG compile body;
Warning: Package Body altered with compilation errors.
SQL> show error
Errors for PACKAGE BODY APPS.AP_PAYMENT_EVENT_CORE_PKG:
Regards
Kiran Rana

Thanks,
It is solved with following documetn over metalink:https://metalink.oracle.com/metalink/plsql/f?p=130:14:1453091699489949037::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,293451.1,1,1,1,helvetica
Doc ID: Note:293451.1
Regards
Krian Rana

Error 113 - UDP

Similar Messages

Maybe you are looking for