LabVIEW
Protocol SMB
Solved!
Applications normally don't talk SMB directly. They make use of some API. SMB is nowadays mostly used for file sharing and other similar appliciations and seldom for inter-application communication, at least directly. Things like Distributed COM might be routed through an SMB connection but that is not common nowadays.
Generally if the server implements SMB for file sharing you will need to setup Windows to connect to it properly and simply access the shared file locations with the file IO APIs in LabVIEW. If for whatever strange reasons you really need to directly talk through SMB you are in for a rough ride.
That would mean accessing Windows APIs directly and some of them are pretty nasty in terms of parameters they use, which would require some complicated vodoo in the VI diagram to call those APIs directly with the Call Library Node or the creation of an intermediate DLL in C(++) that you then call with the Call Library Node. The intermediate DLL would translate between the Windows APIs and a more LabVIEW friendly function API. Both solutions will require you to be steadyfast with C programming in order to create a solution that will not just keep crashing more or less randomly.
Well SMB is still very often at the base of many more simple Windows file sharing solutions. Never mind that it is usually SMB over TCP/IP, since TCP/IP is the ubiquitous low level protocol nowadays. Big changes that if you have a file share on your computer from a Windows server, that you are actually using CIFS (an SMB dialect) for this.
And that is already the answer for the OP. Use of the SMB file sharing protocol is completely independent of LabVIEW. As long as the Windows domain configuration is setup to allow access to the remote share location from your current account you can simply address that file share through an UNC name "\\server_name\share_name\path". The LabVIEW path control under Windows supports UNC paths and therefore you simply use Open File to open that path. Or alternatively you map the remote location in Windows to a local device (e.g. "P:\name") and then access it like any other file on your computer.
The only possible drawback of this is: if the remote location is not available you can end up with pretty long timeout delays when trying to open a directory or file on it, since the underlying network functions work with a preset timeout interval that you have absolutely no chance to change from the file access API.
And if you talk about Linux as client system you would have to make sure that SAMBA is installed (most desktop distributions have that enabled by default), the open source implementation of the Windows SMB client and server and then some more, and configure it such that the remote location is mapped into your file-system by mounting it somewhere into your file-system tree.
Forced to do what?
Describe your problem in more details. What server/hardware? Why SMB? How does your requirements specification look like?
