LabVIEW
XNET Flash Programming is slow
Hi Hoovahh,
I've tried to reproduce your method, but my download speed is still less then 1/3 of what an "official" downloader can achieve. In the image below you can see a PCAN log of the same DL from both methods, the section on the left will send frames with delays as low as 0.03 mS, the right side is LabVIEW struggling to hit 0.2 mS. Is there a setting I'm missing?
That is interesting. I'm glad you were able to complete the process using my drivers but I'm not happy about the longer flash time. I have made some very minor improvements to that state machine over the years, but I didn't think it should improve flash time. I do think there is some room for improvements, but the bulk of the slow down looks like it is in the wait time between blocks of data being sent. This should be contained within the ISO 15765 Transmit Blocks.vi. Just for a test I'd suggest opening this VI, then forcing the case statement to go into case 0. Just hard code a 0 to the select terminal on the case structure. This will happen if there is no separation time from the ECU.
If it still is quite slow after that then I'd suspect it has to do with the driver for the hardware you are using. The example I posted was for KVaser, Intrepid, or Vector drivers. KVaser and Intrepid only support sending one frame at a time and so will call the DLL again for each frame which might introduce a delay. The Vector driver supports writing N frames at once and should only call the DLL once which I think should improve your speed.
Most of my flashing has been on XNet hardware. I do see a slower than ideal flash time on older embedded Linux RT targets. But on Windows the flash time is very close to vFlash. But like I said I have made some changes to the code since posting. One improvement for sure is getting rid of the State Diagram state machine. It is cool to look at, and makes documentation easier, but the code itself is not optimized.
