LabVIEW
VxWorks cRIO not getting response from DHCP server after formatting
Solved!
You realize that all VxWorks (and Pharlap) RT targets are since several years EOL? And LabVIEW support for them ceased with version 2020. This means you should not expect any bug fixes and changes anymore. What is there is there and what isn't, never will come to happen anymore. Not even if you point out a major security vulnerability to them. The development tools are archived, and the hardware on which they still can run was since sent to the electronics scrap processor. The cross development tools for VxWorks 6.3 can't run on anything beyond Windows 7, 32-bit The according Diabolo compiler and debugging IDE nether and it was not only insanely expensive but is also not available anymore.
When you reformat a controller, a basic boot loader is installed and nothing more. This bootloader is a minimalistic version of the OS that just comes with the barely necessary stuff to get the hardware into a state where it can be accessed over a terminal, provide a file system for the on board hard disk, and serve minimal network options. Under Linux this is best comparable with Grub, but for these targets it uses its own basic boot loader that VxWorks normally uses. Once you install a specific version of the LabVIEW RT Runtime platform, the actual Vxworks 6.3 (6.1 if you use LabVIEW 8.2) based OS is installed. And this is the version that seems to work fine with your DHCP server. How much the bootloader is configurable is probably something that is only "maybe" documented in the VxWorks SDK documentation, but you can't officially get that anymore for these versions (and had to buy it back in those days, for a significant amount of bucks). The way to deal with the bootloader was back in those days to enable the terminal of the device and attach a serial terminal (emulator) to it. Then use the bootloader commands to do things. Full network support in the bootloader itself was usually more experimental than anything else.
Unfortunately it's not just NI which ceased support for these OSes. Virtual Zero discontinued Pharlap ETS in 2013 and WindRiver discontinued VxWorks 6.8 in 2019 and put VxWorks 6.9 into Legacy mode in 2020, to be EOLed soon. But NI uses VxWorks 6.3 which has been long since already EOLed.by WindRiver. You may say, why did they not just upgrade to a later supported version and the answer is simple. The PPC platforms were designed at a time when Intel had serious trouble with their CPUs to perform well without being a good replacement for your central heating system too. PPC at that time had a very good performance/power ratio in comparison. With the release of Atom and especially the new Core architecture Intel finally managed to get into the power efficient region and their CPUs got a viable option for embedded hardware. And with the ubiquitous presence of the x86/64 architecture everywhere, it was the logical choice for new designs and the Linux OS in a realtime optimized form was the obvious choice, rather than trying to use yet another specialized realtime OS that may or may not get discontinued at the whim of the manufacturer. VxWorks still is around, but their record of providing 16 years of active support for VxWorks 5.5 (from 2002 to 2018) hasn't been quite continued and they typically discontinue even long time support versions after 10 years or less and in between versions like 6.3 that NI used even sooner.
