Project

General

Profile

Task #24578

ACNET Connection

Added by Shrividhyaa Sankar Raman 4 months ago. Updated 2 months ago.

Status:
Work in progress
Priority:
High
Start date:
08/03/2020
Due date:
% Done:

90%

Estimated time:
Spent time:
Duration:

Description

  • Attempts to connect HWR system to ACNET initiated.
  • Parameter Spreadsheet files attached to enable as ACNET devices.
hwr_param_data_dev.csv (56.7 KB) hwr_param_data_dev.csv Devlopment station Shrividhyaa Sankar Raman, 07/08/2020 08:20 AM
hwr_param_data1.csv (56.7 KB) hwr_param_data1.csv HWR Cntrl1 Shrividhyaa Sankar Raman, 07/08/2020 08:20 AM
hwr_param_data2.csv (56.7 KB) hwr_param_data2.csv HWR Cntrl2 Shrividhyaa Sankar Raman, 07/08/2020 08:20 AM
hwr_param_data3.csv (56.7 KB) hwr_param_data3.csv HWR Cntrl3 Shrividhyaa Sankar Raman, 07/08/2020 08:20 AM
hwr_param_data4.csv (56.7 KB) hwr_param_data4.csv HWR Cntrl4 Shrividhyaa Sankar Raman, 07/08/2020 08:20 AM
ACNET_Term.JPG (220 KB) ACNET_Term.JPG Shrividhyaa Sankar Raman, 07/30/2020 09:03 AM

History

#2 Updated by Shrividhyaa Sankar Raman 3 months ago

  • File deleted (hwr_param_data2.csv)

#3 Updated by Shrividhyaa Sankar Raman 3 months ago

  • File deleted (hwr_param_data1.csv)

#4 Updated by Shrividhyaa Sankar Raman 3 months ago

  • File deleted (hwr_param_data3.csv)

#5 Updated by Shrividhyaa Sankar Raman 3 months ago

  • File deleted (hwr_param_data4.csv)

#6 Updated by Shrividhyaa Sankar Raman 3 months ago

  • File deleted (hwr_param_data_dev.csv)

#7 Updated by Shrividhyaa Sankar Raman 3 months ago

  • % Done changed from 0 to 60

The code for ACNET support has been developed and can be run as soon as a few small bugs have been addressed.

#8 Updated by Dennis Nicklaus 3 months ago

I created Acnet devices for 8 HWR cavities today. Awaiting coordination with PIP2IT ops and Shrividhyaa to actually attempt to communicate with HWR controllers from the Acnet/erlang frontend.

#9 Updated by Shrividhyaa Sankar Raman 3 months ago

  • % Done changed from 60 to 70
  • HWR ARM code was tested for connection to ACNET successfully.
  • Next step is to establish simultaneous connection with ACNET and LabVIEW.
  • Working on diagnosing the cause for this issue.

#10 Updated by Shrividhyaa Sankar Raman 3 months ago

  • Front End ARM code communicates with LabVIEW but LabVIEW is not getting populated.
  • Can see all the changes made on the front end but LabVIEW is only populated with 0s.
  • Problem may be with the header that tries to contact LV.
  • Mr Nicklaus claims when he tried to access the ACNET values for Systems 2, 3 and 4, he saw LV values on port 3001 (programmed in the old code).
  • Both ACNET and LV worked in conjunction at one point. However, they were not synchronized.
  • Testing to continue...

#11 Updated by Shrividhyaa Sankar Raman 3 months ago

  • Went through Mr Chase's email and suggestions from Ed.
  • Deactivated all ACNET related functions.
  • The LabVIEW thread from Ed's code has been remodeled in the new code: the name is now receiver thread. This branches into the labview and ACNET threads, after establishing and checking for authenticated clients.
  • Although the ACNET related functions are deactivated, the ERLANG server still tries to connect. But since the ACNET parts of the code are inactive, these connection requests are declined and terminated. (Image attached below)
  • DAQ thread still not working.
  • However, upon closer look, stream client sclient maybe causing the DAQ thread to stall.

Further updates on this soon.

#12 Updated by Brian Chase 3 months ago

Shrividhyaa Sankar Raman wrote:

  • Went through Mr Chase's email and suggestions from Ed.
  • Deactivated all ACNET related functions.
  • The LabVIEW thread from Ed's code has been remodeled in the new code: the name is now receiver thread. This branches into the labview and ACNET threads, after establishing and checking for authenticated clients.
  • Although the ACNET related functions are deactivated, the ERLANG server still tries to connect. But since the ACNET parts of the code are inactive, these connection requests are declined and terminated. (Image attached below)
  • DAQ thread still not working.
  • However, upon closer look, stream client sclient maybe causing the DAQ thread to stall.

Comments - Brian
We see the threads are started. The code has been modified from older code that was working so I think it safe to point there.
We do not really know if the DMA process is running. Diagnostics?

Further updates on this soon.

#13 Updated by Shrividhyaa Sankar Raman 3 months ago

  • The add_client function worked for the the client connection but not for the stream clients.
  • The stream client value was not displayed due to a mutex that was not released.
  • Once the mutex was removed from the add_client function, the code seemed to run as usual.
  • However, this block of code is not required for LV and therefore has been removed.

Conclusion: Semaphores/mutexes are pobably the reason for the DAQ stalls.

#14 Updated by Shrividhyaa Sankar Raman 3 months ago

  • Start date changed from 06/30/2020 to 07/30/2020
  • Got to this point by removing stream clients across the code as we are not using stream clients for ACNET either.
  • This seems to have caused the issue with the DAQ thread updating values.
  • Will continue to work on this.

#15 Updated by Shrividhyaa Sankar Raman 3 months ago

  • There is synchronized behavior on ACNET and LV as far as the parameters are concerned.
  • Still no updates on Waveforms.
  • Will continue working on this on Monday.

#16 Updated by Shrividhyaa Sankar Raman 3 months ago

  • Not printing waveforms due to the condition, "if(sys->param[par_idx].lv_wv[lv_idx] == true)" in the DAQ_thread part of the code.
    => Value false.
  • Assigned to true in LV_commands when requesting for waveforms. Why is the condn failing?
    =>Print value when assigned to true -> Value: 1.
    => Print lv_idx when assigned to true -> LV_idx: 2.
  • Print lv_idx in the DAQ_thread when value is used -> LV_idx: 0.
  • Why is LV active at 2 in LV_commands and 0 in the DAQ_thread?

#17 Updated by Shrividhyaa Sankar Raman 3 months ago

  • Start date changed from 07/30/2020 to 08/03/2020
  • When LV_commands is called, lv_idx is passed to it by labview_if_recv.
  • labview_if_recv also receives its lv_idx value from receiver_thread.
  • Therefore, the source of the problem is at the receiver_thread where the lv_idx is passed.
  • When labview_if_recv is called in the receiver_thread, the lv_idx loop ends much before the function is called.
  • Therefore, lv_idx value would be Max_lv_clients-1 when passed.
  • Having a for loop for lv_idx and calling the function for the lv_idx that has an active client solved the waveform issue on LV.

#18 Updated by Brian Chase 2 months ago

Needs updating.

#19 Updated by Shrividhyaa Sankar Raman 2 months ago

  • % Done changed from 70 to 90
  • Status changed from New to Work in progress
  • The problem with the ACNET code was an issue with the received packet from ther ERLANG server.
  • The ARM code went out of sync and the received packet accumulated over time before the SP and FF table values were updated in memory.
  • Thus, the coding for the read operation was altered for ACNET.
  • It reads the first 4 bytes of data which determines the number of bytes of data and then the data itself.
  • This solves the issue of synchronization and string length error.
  • This still did not allow LV to work.
  • The function labview_if_receive was assigning all clients inactive which caused the LV to stop updating.
  • Commenting this block of code solved the updation of LV.
  • Tried changing values on LV and on ACNET to see the change in the other.


Also available in: Atom PDF