We have determined through direct phone contact that the advanced baud rate can not be done with XNET alone, that it requires a combination of XNET and older NI-CAN since the XNET C API requires the implementation of the XNET CAN Database , which has a baud rate parameter that only accepts a "Standard defined baud rate, i.e. 125000,25000,etc.." . Any custom baud rate setting in that is implemented if not in the "Standard list" of baud rates as defined in the NI XNET API, and not matching the database parameter will generate the error "Invalid Baud Rate".
At this point we are kind of frustrated that it was made to sound simple and doable to set our custom Baud Rate, and finding now that it requires such extensive , unclear , measures to get the XNET based 8513 to accept a custom baud rate. The rate we need is 666.667K, but found that any custom rate ( valid custom baud , which should be allowed with the 8MHz transceiver, and is / was doable in the older NI-CAN cards), produces an error with the XNET based cards /API.
Under direction from NI support, my supervisor has been working with, we are attempting to work out the required NI-CAN , NI-XNET, combination of C API code to make this work ( unsuccessfully so far). If you have any ideas that may help it would be appreciated, as our deadline to make this functional is over due.
Just to answer some of your questions:
The multiple values were input as I was trying to make the XNET work and was trying several different approaches.
The get property function was not returning the *Property Value. I do realize that the convert from u32 to int was going to give me a different value, I was trying to get any return at all instead of nothing.
I am working to get you a solution. I will let you know when I have validated your code and or have working code.
Thanks for all the help. We have started from square one, using the Sample code provided from NI install. Sample project is NI-XNET\CAN\Signal Single Point OutPut. We have finally got this working..I'll share some insight that I have learned maybe if someone else comes up with same issues.
1) It will work with XNet , I found though with help of NI Support on Reference#1808787, that as long as I set the nxPropSession_IntfBaudRate with a hard coded value(i.e. HEX 0x8XXXXXX, or decimal equivalent), then no problem. It's when I use the macro in the nixnet.h that was and is giving me the issues. The odd thing is, if I take the hard coded hex value 0x8018007D and convert to decimal , I get the exact same value as the macro produces, but for some reason when I set a variable equal to the macro output and pass that variable it generates errors. ( It is possible that somehow I am doing something to cause thise , but in this simple example I don't see it).
2) I still can not seem to get the function nxGetProperty to give me what it thinks is the Property Value. My Code: g_Status=nxGetProperty(g_SessionRef,nxPropSession_
I then code to printf("PropertyValue",Prop_Baud) which prints "Property Value "
Now I am not an expert at C by any means, but if I do something like :
then I get : "Value 30"
Can you tell me am I missing something specific to the function?
3) We also noticed that if we use MAX and the NI-CAN software layer, that we can not get a custom baud to work with the Test Panel. Under the Reference # above I supplied the following information:
using the NI MAX software, I imported samples from the NI CAN Database example.ncd into the Data Neighborhood \CAN and set the hardware for CAN0 to a baud of 666.667K which seems to work fine in setup. However when using the Test Panel for one of the imported channels, we receive an error indicator and details indicate invalid Property, Attribute or Op value, when we attempt to transmit. Changing the baud rate setting on CAN0 back to a "Standard" baud of 125K, 250K etc.. , and re-running the test panel on the same imported channel I am able to transmit the message just fine."
Does the Test Panel feature only work with "Standard Baud Rates"?
Thanks Again for all the help so far,
I have been working closely with the engineer in charge of the service request you mentioned. We will update you when we have answers to these questions.
Thank you for your patience!