The problem with a PC/Windows based serial data exchange over a virtual serial port, ie a USB link with a driver IC that makes it look like a uart at the end, ie a FTDI device, is that USB is not optimised in anything like the same way as a native uart. USB is designed to move a reasonable amount of data, at a reasonable speed, but under conditions where the latency, delay and interbit timing of that data isn't really important.
For example, you put a usb memory stick in the usb socket, and transfer a file up to your PC, and while you do want all the file and it to be all intact ie not full of bit errors, you don't actually care, to the nearest millisecond, how or when it got there.
For an embedded system trying to avoid collisons on a serial bus of any format, then unless you data rate is incredibly slow, then you need ms level timing accuracy and critically repeatability. A VCP on a PC does not allow this, well, certainly not with std drivers, but even, with custom RTOS it is still dificult in my experience.
So, the solution is to use a slave node as an interface and that embedded node gets data from the PC running the control software, but it acts in a way to buffer that data and hence you can now have asyncronous coms to the pc, and synchonous coms to the slave network.
If you have am RS-485 network with a master controlling the flow, then that master can issue ms or shorter timming sync messages, and your individual slaves can act on those messages and reply when you know there isn't going to be a collision. here, your "interface slave" acts to buffer any data exchange to the pc to fit neatly into the master led timing of that slave bus. That slave can have a descrete data link to the pc via a FTDI or similar.