Labview cannot send command error
Some general comments that are better suited to an answer versus multiple small comments (which are discouraged here).

Does your VI check the instrument's present state before the VI sends a new command to the instrument? A common programming error is to send the instrument a command when it is in a runtime state that prevents it from accepting new commands&mdash;e.g.,the previous command has not yet completed; an invalid command was sent to the instrument, the instrument did not understand the command, and the instrument is now in an error state, etc.

When a VI sends a command to an instrument, the VI must next ensure the instrument fully and successfully executes that command before the VI sends the instrument a new command.  This is done by testing the OPERATION COMPLETE bit and the various ERROR bits in the instrument's EVENT STATUS REGISTER (ESR).  Your VI sends the instrument an *ESR? query and the instrument sends back the 8-bit value from its ESR.  Your VI then tests the states of the OPERATION COMPLETE bit and the ERROR bits in that 8-bit return value.
(NB: Some instruments have a 16-bit ESR. See your instrument's documentation to determine the number of bits and the bit assignments for the ESR in your instrument.)
(NB: Set bits in the ESR remain set until (a) they are read via *ESR? whereupon they are cleared (except for the POWER ON bit), or (b) they are cleared by sending the instrument the CLEAR STATUS command, *CLS.)

See also the OPERATION COMPLETE query *OPC?.
NB:&nbsp;On page 153 of Keysight's SCPI Command Reference manual for the N5173B (document ID N5180-90057.pdf) you'll find the following statements regarding the *OPC? querry:


  This query stops any new commands from being processed until the
  current processing is complete. This command blocks the controller
  until all operations are complete (i.e. the timeout setting should be
  longer than the longest sweep).
  
  CAUTION 
  The *OPC? query is not recommended for checking if a previous command
  has been completed by the SCPI parser. (e.g. If the *OPC? query is
  waiting for a sweep or arb generation that is pending, it could
  potentially hang the *OPC? query for an undefined extended or even
  indefinite period of time.)


For instruments that perform measurements, research the MESSAGE AVAILABLE (MAV) flag (bit 4) in the STATUS BYTE REGISTER.

If you discover that the instrument is asserting one or more ERROR flags in its ESR, I suggest you save and close your VIs, close the LabVIEW application, and then use instead a VISA test panel within NI's Measurement Automation Explorer (NI MAX) program to debug these errors.  For example, use the test panel to send the instrument the exact same command string that your VI sends to the instrument, and then use the test panel to query the instrument's ESR (send *ESR?) to determine if the instrument understood the command string and executed it successfully.
(NB:&nbsp;THIS WEBPAGE on NI's website discusses GPIB-connected instruments, but the information is also useful for instruments connected via USB, Ethernet, etc.)

See section 3.9 "Oops typo" and chapter 4 "Instrument Status" in Rob Limburg's GPIB tutorial (PDF).  (NB:&nbsp;The subsections in section 3.9 are mislabeled as 3.8.x.)

By the way, I've written LabVIEW VIs that (while still under development) exhibit the behavior you describe where the VI runs once, but all subsequent attempts to run the VI result in error codes or the VI just hangs.  This suggests that my VI caused an NI service or shared library to become unstable. When this happens, I find I can usually (but not always) regain control by (a) power cycling the instrument, AND (b) logging out and logging back in on the computer I'm using. When a user logs out, the operating system (OS) usually unloads from memory any processes or shared libraries that were loaded into memory during a user's login session. As a result, when I log back in and re-launch LabVIEW, the OS reloads the LabVIEW-related services and shared libraries into memory from disk and I get a fresh start (everything works again).  Every once in a while, however, the logout/login cycle doesn't help and the only resort then is to reboot.